PyTimechart
in [Kernel]
|
From: Steven Rostedt on 12 May 2010 13:20 On Wed, 2010-05-12 at 18:59 +0200, Ingo Molnar wrote: > * 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. Actually, trace-cmd implements the splice interface and is used by several people. I find myself using trace-cmd 90% of the time that I use ftrace, specifically because of this speedup. > > 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. I'll have start running benchmarks to see what the actual speed up is. I'm guessing it may be more than a few percent. It allows for zero copy overhead and reuse of the data page. -- 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: Pierre Tardy on 12 May 2010 13:20 On Wed, May 12, 2010 at 4:48 PM, Frederic Weisbecker <fweisbec(a)gmail.com> wrote: > 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. I mean that perf timechart record is implemented as an hardcoded perf record call. Typically, user wants to add is own events for pytimechart to display them in a generic manner. I agree this is a trivial change. > > Why not starting with a release that does the same things > than timechart and trying to integrate the rest incrementally? Yes, I'll see what I can do. > The code I'm looking at here doesn't look dirty to me at a glance: > http://gitorious.org/pytimechart/pytimechart/trees/master That's because you did not read between the lines ;-) The display core needs to be simplified. 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: Ingo Molnar on 12 May 2010 14:30 * Steven Rostedt <rostedt(a)goodmis.org> wrote: > On Wed, 2010-05-12 at 18:59 +0200, Ingo Molnar wrote: > > * 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. > > Actually, trace-cmd implements the splice interface and is used by several > people. I find myself using trace-cmd 90% of the time that I use ftrace, > specifically because of this speedup. i know, but most people still use /debug/tracing/ bits not trace-cmd. > > 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. > > I'll have start running benchmarks to see what the actual speed up is. I'm > guessing it may be more than a few percent. It allows for zero copy overhead > and reuse of the data page. Make sure you measure it in the context of a full app like PyTimechart. You can measure the overhead using perf stat ;-) 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/
From: Arnaldo Carvalho de Melo on 13 May 2010 11:10 Em Wed, May 12, 2010 at 07:13:00PM +0200, Pierre Tardy escreveu: > > The code I'm looking at here doesn't look dirty to me at a glance: > > http://gitorious.org/pytimechart/pytimechart/trees/master > That's because you did not read between the lines ;-) > The display core needs to be simplified. Not even having looked at the code, I like your attitude! :-) - Arnaldo -- 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/
First
|
Prev
|
Pages: 1 2 Prev: [RFC] PyTimechart Next: [PATCH] MMC: OMAP HS-MMC: convert to dev_pm_ops |