Date:	Sat, 17 Jan 2009 14:48:30 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chris Mason <chris.mason@...cle.com>
Subject: Re: [PATCH 0/2] ftrace: updates to tip

On Fri, Jan 16, 2009 at 08:14:25PM -0500, Steven Rostedt wrote:
> 
> On Fri, 16 Jan 2009, Ingo Molnar wrote:
> 
> > 
> > * Ingo Molnar <mingo@...e.hu> 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 could use a kind of ftrace_filter thing which would be a list of callbacks
to call, depending of the options set.

This would add one condition to verify for each function in the best case.



> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists