Date:	Thu, 10 Dec 2009 23:40:21 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Tim Bird <tim.bird@...sony.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Li Zefan <lizf@...fujitsu.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] ftrace - add function_duration tracer

On Thu, Dec 10, 2009 at 04:55:43PM -0500, Steven Rostedt wrote:
> On Thu, 2009-12-10 at 21:23 +0100, Frederic Weisbecker wrote:
> > Oh no, I'm not planning to use tracepoints for that.
> 
> Thank goodness ;-)


:)


 
> > 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.
> 
> Hmm, please keep the use of struct tracer around. That is still a very
> powerful utility.


Sure. The goal is to move the function graph tracer into a
more unified interface that can profit to a wider range of
uses (perf being the new user I have in mind), and also to
make it easier to use concurrently.

But I'm not dropping struct tracer, as I too think that until
we have something superior (and not only potentially superior),
we need to keep it. And I'm pretty sure we all think the same.

But if I convert the graph tracer into the trace event interface,
I guess we shouldn't maintain its struct tracer version in
parallel.

 
> > 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.
> 
> Yeah, this gets a bit complicated. The biggest issue is that the mcount
> call is not C abi, so it must go through some sort of trampoline. I've
> thought about making a dynamic trampoline, but again, that will start
> hogging up memory, and I'm not sure it is worth it.


Yeah, that would be too complicated and hard to maintain.

 
> I gave this some thought, and the best we could do is have a ref counter
> with the ftrace record itself. We need a global flag to know if all
> functions need to replace a nop to trace caller, or just some. That way
> we can have one tracer tracing all functions and another tracing just
> some. We sorta have that today though.
> 
> Making the API to this infrastructure will also take some thought. We
> currently can register a function to be called by the function tracer
> (we can today register more than one). But the filtering is at a global
> level. We need a way to have a tracer tell ftrace that it wants to trace
> all or some functions, as well as make up its mind later. Then this
> function can be called by all, or if a function in some hash table says
> its OK to be called.


Yeah, I thought about that too.
May be can we keep the current list of ftrace records.

Then when a random function tracer registers, we give it
a dedicated hashlist of functions (which kind of mirrors
the ftrace records, but in a hashlist fashion).

When it wants to trace a set of functions, we set appropriate
flags in its hashlist and the ftrace core patch the sites if
needed.

Once we want to disable tracing on functions, we disable it
on the tracer hashlist, then the ftrace core goes through
the list of every tracer hashlist and counts the current
users of the function, if there are no more of them, we nop
back the site. Well, that could be refcount in ftrace records
too.

But the point is this hashlist. I don't think it will be that
much a huge memory consumer as I don't expect there will ever be a
lot of concurrent function tracing users at the same time.

I just hope we can make it smart enough to be a near true O(1)
hashlist.

Just an idea...

--
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