PyTimechart
in [Kernel]
|
From: Frederic Weisbecker on 11 May 2010 17:40 On Tue, May 11, 2010 at 11:10:36PM +0200, Pierre Tardy wrote: > Hello, > > PyTimechart is another implementation of two very useful tools > available for the linux community: > perf-timechart ( http://blog.fenrus.org/?p=5 ) and bootchart ( > http://www.bootchart.org/ ) > > The two tools share a common idea of making their output to SVG files. > While it is a very good idea for small traces, the generated SVG can > be very heavy, and turns out to be good stress tests for inkscape > developers... > > PyTimechart is a tool that parses ftrace text traces, and display them > with the help of a very powerful dynamic plot framework, Chaco ( > http://code.enthought.com/chaco/ ) > The GUI makes the best it can to ease the browsing of huge traces. > > The best is to look at those two 30s screencasts, to figure out how that work. > > a look at mplayer startup: > http://tardyp.free.fr/pytimechart/mplayer_start.mp4 > a look at ubuntu boot: > http://tardyp.free.fr/pytimechart/boot.mp4 > > This tool still is in the state of a prototype, I dont know if it > worth to continue to improve it or to implement it ideas in LTTV or > Kernel Shark. > It is actually very useful in its current form ( > http://elinux.org/images/0/07/Effect_of_wakeups_on_Moorestown_power.pdf > ), and will work without recompiling the kernel of recent distros. > > the source code with build instruction is located here > http://gitorious.org/pytimechart > > What do you think? I think I've been dreaming about this several times. I've often used perf timechart lately and I'm really frustrated by its inherent slowness due to its huge svg files. It's barely usable with a small trace on two cpus, and it's impossible to go further, which is really a pity for such a powerful tool. IMO, this GUI is exactly what we want. If you could plug it to the perf scripting facilities, I would be very happy to see it merged in perf tools. Plugging to the scripting API is really easy, run: $ perf timechart record $ sudo ./perf trace -g python generated Python script: perf-trace.py Now look at ./perf-trace.py, you'll find all the necessary hooks generated with a default behaviour (displaying traces), which you can observe by launching: $ perf trace -s perf-trace.py You just need to change it to plug your app on it. (Adding more Cc). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pierre Tardy on 12 May 2010 09:40 > Plugging to the scripting API is really easy, run: > > � � � �$ perf timechart record > � � � �$ sudo ./perf trace -g python > � � � �generated Python script: perf-trace.py This is something that I want to try since I saw the perf scripting patch, thanks for the recipe, I'll look at it in the next few days. The next problem is that perf timechart record is frozen on the number of event it records. Pytimechart is able to display irq:* and workqueues:* events, as well as trace_printks ( I dont know if perf is able to dump those ) I use trace_printk to mark the big traces with events I'm trying to debug. Being able to look at ISR and workqueues is very useful, and there is a special feature that warns when an ISR lasts more than 1ms. For inclusion in mainline, this might take more time. The quality of some portion of the code is far from being linux kernel's standards :-} Regards, Pierre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Frederic Weisbecker on 12 May 2010 10:50 On Wed, May 12, 2010 at 03:37:27PM +0200, Pierre Tardy wrote: > > Plugging to the scripting API is really easy, run: > > > > � � � �$ perf timechart record > > � � � �$ sudo ./perf trace -g python > > � � � �generated Python script: perf-trace.py > > This is something that I want to try since I saw the perf scripting > patch, thanks for the recipe, I'll look at it in the next few days. > > The next problem is that perf timechart record is frozen on the number > of event it records. What do you mean? That it can't do incremental records or so? It's supported by perf record, may be not by perf timechart but that would be a matter of a little patch. > Pytimechart is able to display irq:* and workqueues:* events, as well > as trace_printks ( I dont know if perf is able to dump those ) > > I use trace_printk to mark the big traces with events I'm trying to debug. > Being able to look at ISR and workqueues is very useful, and there is > a special feature that warns when an ISR lasts more than 1ms. No problem with the irq and workqueues, if that's really useful, we can change perf timechart to handle this. But we don't yet support trace_printk in perf. May be we could wrap them in trace events. Why not starting with a release that does the same things than timechart and trying to integrate the rest incrementally? > For inclusion in mainline, this might take more time. The quality of > some portion of the code is far from being linux kernel's standards > :-} The code I'm looking at here doesn't look dirty to me at a glance: http://gitorious.org/pytimechart/pytimechart/trees/master -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Steven Rostedt on 12 May 2010 11:40 On Wed, 2010-05-12 at 16:48 +0200, Frederic Weisbecker wrote: > On Wed, May 12, 2010 at 03:37:27PM +0200, Pierre Tardy wrote: > But we don't yet support trace_printk in perf. May be we could wrap > them in trace events. Hmm, do we really want to do that? We really need to get the perf and ftrace trace buffers combined. I understand why perf chose to do the mmap buffers for the counting, but for live streaming, it is very inefficient compared to splice. I would hate to add more duplicate code to have perf support trace_printk(). -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 12 May 2010 13:10 * Steven Rostedt <rostedt(a)goodmis.org> wrote: > On Wed, 2010-05-12 at 16:48 +0200, Frederic Weisbecker wrote: > > On Wed, May 12, 2010 at 03:37:27PM +0200, Pierre Tardy wrote: > > > But we don't yet support trace_printk in perf. May be we could wrap > > them in trace events. > > Hmm, do we really want to do that? > > We really need to get the perf and ftrace trace buffers combined. I > understand why perf chose to do the mmap buffers for the counting, but for > live streaming, it is very inefficient compared to splice. The thing is that for a very long time ftrace didnt have splice support and survived just fine. Even today most of the ftrace usage isnt utilizing splice. Yes, splice might help in some situations but on average it's an independent speedup on the order of magnitude of a few percents, not a 'must have' item. So please keep these issues separate. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Next
|
Last
Pages: 1 2 Prev: [RFC] PyTimechart Next: [PATCH] MMC: OMAP HS-MMC: convert to dev_pm_ops |