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

[Steven Rostedt]

On Thu, 2009-12-10 at 13:13 -0800, Tim Bird wrote:

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

The function graph for arm would be fine. Go ahead, there's no expected
change in this code for the near future, and if it does change it will
be at a higher level (generic code, not arch).

> 
> Are either of these still interesting?

We already have a way to enable arbitrary ftrace plugins at boot time:

Try ftrace=function on the command line.

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

Please do. Again, if we change this code, I would expect it to happen at
a higher level. Trying to do a registry at the arch level will explode
in complexity.

> 
> > 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"?

Well, the TRACE_EVENT infrastructure has made them obsolete. In ftrace
terms, you can just do:

 # echo 1 > debugfs/tracing/events/sched/enable
 # cat /debugfs/tracing/trace

and see basically the same information that sched_switch showed.

> 
> In what time frame will the ftrace plugin feature be obsoleted?

Well, currently we don't have any substitute for function/function_graph
and the latency tracers. We just don't want to be adding more.


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

I don't plan on removing the plugin infrastructure anytime soon.

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

It's not really discussed much. Usually someone pushes out a patch set
that changes the direction of tracing, and we go from there. So yes, it
is LKML.

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

Which tracer was that? I know you used the -finstrument-functions for
tracing before, and that has quite a bit overhead as well. The ring
buffer has gone through a lot to speed it up.

-- Steve


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