Re: [RFC][PATCH 00/13] ftrace: Allow multiple users to pick andchoose functions to trace

[Ingo Molnar]

* Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> 
> Ingo, et. al.
> 
> This is an RFC patch set of the work I did to allow multiple users
> to pick and choose which functions they would like to trace without
> being affected by other users (well, they are still affected, but
> they can choose their own functions).
> 
> Since this rewrote a lot of the guts of ftrace's function handling
> I broke it up into steps that I can sequentially think about how to
> make the conversion. It also helped in understanding the changes that
> had to be made.
> 
> The end result now has this:
> 
>  o The function record list flags item now stores a ref count, and
>    we no longer need to have the flags if the records are filtered
>    or set for "notrace"
> 
>  o Each ftrace_ops has its own set of functions to trace or not trace
>    which is used to update the ref counts of the function records
>    mentioned above. If the ftrace_ops is not currently active, the
>    records are not touched when the filters are changed. If the filters
>    are changed while the ftrace_ops is active, it is done in a way
>    with RCU to make the updates.
> 
>  o If only one ftrace_ops is registered for tracing (actively tracing),
>    its handler is called directly from mcount. Unless the ftrace_ops
>    was allocated and not a static/global core kernel variable (see below).
> 
>  o If more than one ftrace_ops is registered, then a function is called
>    that will iterate over the list of registered ftrace_ops, performing
>    a check of each of its hashes to know if ftrace_ops handler should
>    be called for that function.
> 
>  o If a ftrace_ops is allocated and not a static/global core kernel
>    variable, it will be forced to use the function that loops through
>    the ftrace_ops even if its the only one. This is because that function
>    disables preemption when it performs the loop. This is needed, because
>    dynamically allocated ftrace_ops must call synchronize_sched() before
>    being freed (which is done when the dynamic ftrace_ops has been
>    unregistered).
> 
>  o A file has been created in the debugfs/tracing directory called
>    enabled_functions. This file contains a list of all functions that
>    any ftrace_ops has registered, along with each functions ref count.
>    This can be used to make sure nothing is tracing.

Well, i think we'd like to see the end result as well: i.e. function tracing 
exposed to a tracer that can do per task tracing (perf) and then demonstrating 
that independent tracing sessions can trace functions without impacting each 
other.

Thanks,

	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/