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

[Tim Bird]

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/.

Sigh.  OK - where's the perf code?

It took me a while to wrap my head around ftrace, so if I've
got to switch to a completely different event-ing infrastructure,
it will probably be some time before I'm back again.

I have some patches to add function graph tracing for
ARM, and to make it possible to use arbitrary ftrace plugins
at boot time.  (There are issues with the current code for
anything other than the bootgraph plugin).

Are either of these still interesting?

I was about to start work on dynamic ftrace support for ARM.
What is the status of this?

> 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.

It looks like all the tracers mentioned above are still in 2.6.32,
which was just released. In what sense are they "already obsoleted"?

In what time frame will the ftrace plugin feature be obsoleted?
I'm using this code on 2.6.29 for a variety of Sony products.
If the ftrace plugin stuff isn't going away for another year
or two that gives me several years of utility with the current
code (which I recognize I'd have to maintain myself out-of-tree).

Once things have settled down and you guys have figured out
for sure what's going on, I could come back and try to integrate
these features into perf.  As it stands now, I'm a little wary
of putting much effort into that.

Where are these things discussed?  Only on LKML?  It would be
handy if there were a separate list that could get CC-ed for
ftrace stuff, so I could monitor it more easily for big movements
like this.  I apologize if there is and I've just missed it.

> 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'm a little worried about this.  ftrace is already an order
of magnitude more overhead than the previous tracer I was using.
I don't have ANY experience with perf, but if you're using it
for tracing, that already seems one step removed from it's
original use for reporting performance counters.  The complexity
described in the discussion related to this thread does not
raise my hopes that it will meet my needs.

I guess I'll have to start looking at perf to see if my
concerns are justified.  But first, I've got to get the mainline
kernel booting again on my embedded hardware.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

--
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/