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

    * Steven Rostedt <> 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



     \ /
      Last update: 2011-05-10 10:03    [W:0.026 / U:11.168 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site