lkml.org 
[lkml]   [2011]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 00/13] ftrace: Allow multiple users to pick and choose functions to trace

* Steven Rostedt <rostedt@goodmis.org> 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


\
 
 \ /
  Last update: 2011-05-10 10:03    [from the cache]
©2003-2011 Jasper Spaans