lkml.org 
[lkml]   [2008]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 4/4] tracing/function-return-tracer: Support for dynamic ftrace on function return tracer
    Hi Tim,

    2008/11/26 Tim Bird <tim.bird@am.sony.com>:
    > � wrote:
    > Very sorry I'm coming to this thread late. I didn't notice it until
    > today.
    >
    > Not to question the whole approach, and sorry if this was
    > discussed before, but why wasn't -finstrument-functions used
    > to instrument the function exits. This worked well for KFT
    > (See http://elinux.org/Kernel_Function_Trace). I'm not sure if the
    > function prologue and epilogue modifications done by -mcount are
    > different than -finstrument-functions, but I thought I remember something
    > about Steven testing -finstrument-functions in an early version of ftrace.


    Yes, we discussed it earlier but because of some reasons (kernel size,
    dynamic patching
    cost), we used a stack of return address for each task.
    See the discussion about using -finstrument-functions:
    http://lkml.org/lkml/2008/10/30/372


    > By the way, I'm really excited to see this "function_cost" stuff being
    > worked on. It has proven to be extremely useful for analyzing early boot
    > latencies at Sony.
    >
    > Sorry again I didn't catch this and previous related threads
    > earlier. I have some post-processing tools which might be useful here.


    That would be welcome. Note that the output of this tracer is a bit different
    from KFT. I'm currently working on the a C-like output:
    http://lkml.org/lkml/2008/11/25/389
    So perhaps the post-processing would have to be done in a way quite
    different from this
    used on KFT traces. I don't know.

    > Also, I've found it very handy to have the capability to filter by minimum
    > function duration. Is there any work to do that with the
    > current system. If not, maybe I could take a look at that and see if
    > I can add something.

    Yes there would be some modifications to do so.
    I guess the best thing to do that would be to use the trace_options
    files in which
    any tracer can set some custom flags. See set_flag callback in struct tracer.

    For now, this file can only receive boolean value on particular options.
    For example if you have a tracepid option. You either echo tracepid or
    notracepid to
    set the value on trace_option. Your needs would require this file, and
    this set_flag callback,
    to receive string values, like kernel parameters, by using get_option().
    This way you could set duration=50 as an example.
    This work is more tracing specific than function-return-tracer
    specific (it was renamed function_branch
    tracer recently).

    After that, handling this minimal duration set on function branch
    tracer will be pretty easy. :-)

    One other solution would be to have a dedicated debugfs file for this
    tracer but that would be a pity, IMHO,
    to not let too other tracers having custom options with string values.

    If you want to have a look on the current state, see the -tip tree.

    I will add you in Cc for next patches....
    \
     
     \ /
      Last update: 2008-11-26 20:19    [W:0.026 / U:37.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site