Re: [PATCH 0/2] ftrace: updates to tip

From: Steven Rostedt
Date: Fri Jan 16 2009 - 20:14:41 EST

On Fri, 16 Jan 2009, Ingo Molnar wrote:

> * Ingo Molnar <mingo@xxxxxxx> wrote:
> > > I was afraid you would say that :-)
> > >
> > > Yes, we could add something to do this. It would take some thought on
> > > a good api, and implementation. This is not an easy task by any means.
> > > We need a way to map between a function call and a tracer, where a
> > > function call can call more than one tracer.
> >
> > Note that some other things could be consolidated under per function
> > metadata: for example set_graph_function - which really is a per
> > function attribute too. Plus a lot of new things would be enabled i
> > think.
> a few other things that could be per-function attributes:
> - Using function trace 'limits': trace a function 50 times and dont trace
> it afterwards. Each invocation of that function decreases the
> remaining-count by one. For example:
> echo 'btrfs_join_transaction:#2' >> set_ftrace_filter
> Would specify that we generate two trace entries of
> btrfs_join_transaction(), then stop tracing this function.
> - Using function-triggered tracing: a function could be specified (via a
> filter format extension) to act as a 'start tracing' trigger. Another
> extension would be 'stop tracing' trigger.
> For example:
> echo 'btrfs_join_transaction:+' >> set_ftrace_filter
> echo 'btrfs_commit_transaction:-' >> set_ftrace_filter
> The '+' is a start-tracing trigger condition, the '-' is a stop-tracing
> trigger condition. All function calls between btrfs_join_transaction()
> and btrfs_commit_transaction() would be traced.
> The two could be combined - to generate the trace of a single btrfs
> transaction, one could do:
> echo 0 > tracing_enabled
> echo 'btrfs_join_transaction:+#1' >> set_ftrace_filter
> echo 'btrfs_commit_transaction:-#1' >> set_ftrace_filter
> echo 1 > tracing_enabled
> Other extensions are possible too:
> - Trace length triggers. For example one could do:
> echo 'btrfs_join_transaction:+*#10' >> set_ftrace_filter
> To trace 10 function calls [allowed by current filter settings] after
> the first btrfs_join_transaction() call - and stop tracing after those
> 10 trace entries.
> This would allow the creation of "surgical" one-time traces - of events
> and functions one is specifically interested in.

This all sounds great, but it would add a lot of conditionals into a
extremely hot function tracer path. Remember, we are not modifying the
calls to mcount to call a registered function directly. All functions
being traced must call the same function. The reason is that mcount is not
a normal function in C. It does not behave the same as other functions,
and must be implemented in assembly (as you already know ;-) The dynamic
tracer calls into a trampoline that calls the registered function. There
is only one trampoline, so only one function gets called on a trace. We
can at most enable or disable a given function. We can not change what
that function calls (without implementing it for every arch).

This means any conditional that you make, must be made for all traced
functions. And this will put an overhead onto the system.

Now we can register multiple functions to be called by a traced function,
or pick and choose what function will be called by a traced function
depending on what option was asked for. But all traced functions will
still call the same code. We can start experimenting, but I would
be more keen on how this will be used by developers. Chris gave a great
example of how he would use his feature. Doing what you ask would require
a rewrite of most the code. I hate to do that and have only 2 or 3 people
using it :-/

-- Steve

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at