Re: [PATCH 0/2] ftrace: updates to tip

[Steven Rostedt]

On Fri, 16 Jan 2009, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> > [...] We can register a function to be traced via the function pointer, 
> > and we can pick which functions to trace, but we can not separate out 
> > different functions for different traces.
> 
> Why not? We could have a hash of all traced functions with metadata 
> attached. Since patching functions in/out would be a relatively rare 
> operation, this would be a highly efficient read-mostly hash.

I was afraid you would say that :-)

Yes, we could add something to do this. It would take some thought on a 
good api, and implementation. This is not an easy task by any means. We 
need a way to map between a function call and a tracer, where a function 
call can call more than one tracer.

Probably be best for the tracer to have its own hash. This way the tracer 
could do a look up to determine if it should record or not. When filtering 
on a function, it is all functions that get called that are registered. 
For instance, the stack_tracer hooks to all functions to test the size of 
the stack. When the function tracer is hooked in, it does not notice that 
a stack tracer is there.

But we could design it that with the "function[:tracer]" api to 
set_ftrace_filter. Where if you specify a ":tracer" it will only effect 
those functions. In fact, we could have those functions be the only one 
that call multiple tracers. Right now, if only one function is added, the 
dynamic tracer will have the mcount call that function directly. If you 
add a second function (in the case of the stack tracer and function tracer 
running simultaneously) it will change mcount to call an internal function 
that calls each registered function. With a new design, we can have some 
functions call a function together, or call the list. We could have the 
list check the hash to determine which function to call, but that may be 
difficult.

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