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

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 2009-12-10 at 17:52 +0100, Ingo Molnar wrote:

> > Note, we also need a way to "store" the max. The fly recorder method 
> > is not good enough.
> 
> Yeah. What we want in the larger scheme of things is to have operations 
> connected to events. One such operation would be "start measuring max", 
> another would be "stop measuring the max".
> 
> [ Whether the max is intrinsic to the context structure, or is perhaps 
>   some _third_ event (so the max can be recovered by observing that 
>   event) is a detail. ]
> 
> Note that other operations make sense as well, such as:
> 
>  - if event X happens then enable event Y
>  - if event X happens then disable event Y

This is exactly what I was implementing, but I got pulled off to do
other things before I completed it. The idea is to use the filtering
infrastructure to be able to start or stop other events.

> 
> A popular use of that would be to enable the function events on the 
> 'start' event of a latency measurement, and disable function events on 
> the 'stop' event.

Function events will need to be start and stopped via a variable. It's
too much overhead and risk to do the full patching.

Code already exists that is like this. It is done in the function graph
tracer with set_graph_function, and the function tracer set_ftrace_pid.

> 
> Yet another use would be to enable cache miss events when 'entering' a 
> specific function event, and disable cache miss counting on 'exiting' 
> that function. (this would be an event of the function graph tracer)

This could tap into the "set_ftrace_filter" infrastructure. I'm not
saying that it needs to use that file. But that file supports setting
specific actions to a particular function. We could extend the interface
(if it isn't already there) to allow a perf ioctl or whatever to do the
same thing.


>  
> This would allow the precise cache miss profiling of a given function 
> and all its sub-functions - and only of that function.
> 
> Note that the existing filter engine functionality connects in a natural 
> way here as well: it can already be used to limit events and thus can be 
> used to further shape the behavior of tracing, runtime.

Yep.

> 
> Other interesting event operations are possible as well. Key is to 
> expose this via the unified interface and to stop adding new 
> functionality-limited crap via the ftrace plugin infrastructure - it's 
> clearly not suitable for this purpose. We now have found how to do these 
> things properly and cleanly.

Yes, I agree that we should not add any new plugins. But I will still
maintain the ones that are there until we have a replacement. I can
continue my work on getting the events to pass data, and also add a
kernel API to access hooks to functions.

> 
> And the thing is, _you_ implemented unified ftrace events, all i'm 
> asking you is to realize the power of them and to stop adding new 
> ftrace-plugins [which are crap in comparison] and contcentrate on 
> exposing new tracing functionality via unified ftrace events, ok? ;-)

Ah, I think we had a misunderstanding here. I was defending the current
plugins and that they still needed to be supported (I'm working on some
enhancements now). But I agree that no new plugins should be introduced,
and that work should happen on finding alternatives. But until
alternatives are ready, I'll still maintain the current plugins that are
there. If anything, they help us understand what needs to be done with
whatever replaces them.

I think you thought I was pushing to extend plugins. That wasn't my
argument. I was just arguing that the plugins still serve a purpose and
I'll support and maintain the current plugins until they become
obsolete.

-- Steve