[lkml]   [2009]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/4] ftrace - add function_duration tracer
    On Thu, Dec 10, 2009 at 09:29:27AM -0500, Steven Rostedt wrote:
    > On Thu, 2009-12-10 at 13:03 +0100, Frederic Weisbecker wrote:
    > > This makes me feel I'm going to try converting the function graph tracer
    > > into an event during the next cycle. It does not mean I could make it
    > > usable as a perf event right away in the same shot that said, as you can
    > > guess this is not a trivial plug. The current perf fast path is not yet
    > > adapted for that.
    > I curious how you plan on doing this. The current event system shows one
    > event per trace point. A straight forward approach would make every
    > entry and exit of a function a trace point and that would lead to a very
    > large kernel to handle that.

    Oh no, I'm not planning to use tracepoints for that.

    > Perhaps we could abstract out all entries and exits. We need to be able
    > to link to a single point (entry or exit) not all. This also has the
    > added issue of using the ftrace infrastructure of nop the mcount call.
    > We also need a way to enable a set of functions.
    > We may be able to abstract this out, but I'm hesitant on making this the
    > only interface.

    Hmm, yeah. The idea was just to move the use the struct trace to struct
    trace_event. This would be about straightforward. A bit like kprobes: by
    not using the TRACE_EVENT macros (would be impossible anyway) but
    specific callbacks.

    It would be one event.

    set_ftrace_filter and set_graph_function can still be used to further
    control dynamic patching. That's what I intended for a first conversion.

    Another idea would be to abstract it through one trace event subsystem
    that has one event per function. But that sounds a bit too much in term
    of memory footprint. Also it's perhaps sufficient to abstract the
    dynamic patching, but not enough to abstract set_graph_function.

    But later on, a full trace event integration would probably imply
    dicossiating dynamic tracing from the two function tracers.
    For example if the function graph tracer asks to nop a function,
    this shouldn't be propagated to a parallel function tracer user.
    That's even worse once we get a perf integration, we can have
    multiple parallel users of the function tracer. And patching
    should probably adapt to parallel uses, maintaining a kind of
    refcounting, extending the current function hashlist we have
    for function profiling could probably help for that.

     \ /
      Last update: 2009-12-10 21:25    [W:0.021 / U:30.356 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site