Re: [PATCH 2/4] ftrace - add function_duration tracer

[Ingo Molnar]

* Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:

> On Thu, Dec 10, 2009 at 08:08:00AM +0100, Ingo Molnar wrote:
> > 
> > * Tim Bird <tim.bird@xxxxxxxxxxx> wrote:
> > 
> > > Add function duration tracer.
> > > 
> > > Signed-off-by: Tim Bird <tim.bird@xxxxxxxxxxx>
> > > ---
> > >  kernel/trace/Kconfig          |    8
> > >  kernel/trace/Makefile         |    1
> > >  kernel/trace/trace.c          |   32 ++
> > >  kernel/trace/trace_duration.c |  527 ++++++++++++++++++++++++++++++++++++++++++
> > >  4 files changed, 568 insertions(+)
> > 
> > Please do it in a cleaner an more generic fashion: add a "function 
> > event" that perf can see and process, so all the output embellishment 
> > can be done outside of the kernel, in tools/perf/.
> > 
> > We want to wind down the current maze of ftrace plugins, not extend 
> > them. We already obsoleted the following ftrace plugins: scheduler, 
> > sysprof, blktrace, kmem, scheduler, etc. There's more work ongoing and 
> > broad agreement between folks developing it that this is the way 
> > forward.
> > 
> > The function tracer / function graph tracer is a holdout due to its 
> > complexity - but that by no means weakens the argument and the necessity 
> > to migrate it.
> > 
> > ftrace plugins were a nice idea originally and a clear improvement over 
> > existing alternatives, but now that we've got a technicaly superior, 
> > unified event framework that can do what the old plugins did and much 
> > more, we want to improve that and not look back ...
> 
> 
> I agree. If we can abstract it out in a struct trace_event rather than 
> a struct tracer, then please try. I doubt we can't.
> 
> The trace events are more unified.
> 
> This makes me feel I'm going to try converting the function graph 
> tracer into an event during the next cycle. [...]

Great!

> [...] It does not mean I could make it usable as a perf event right 
> away in the same shot that said, as you can guess this is not a 
> trivial plug. The current perf fast path is not yet adapted for that.

Yeah, definitely so. I'd guess it would be slower out of box - it hasnt 
gone through nearly as many refinements yet.

> But at least this will be a good step forward.

Yeah.

Also, i'd suggest we call unified events 'ftrace events', as that is 
what they really are: the whole TRACE_EVENT() infrastructure is the 
crown jewel of ftrace and IMO it worked out pretty well.

I hope there wont be any significant culture clash between ftrace and 
perf - we want a single, unified piece of instrumentation 
infrastructure, we want to keep the best of both worlds, and want to 
eliminate any weaknesses and duplications. As long as we keep all that 
in mind it will be all fine.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/