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    [from the cache]
©2003-2011 Jasper Spaans