|| ||Frederic Weisbecker <fweisbec-AT-gmail.com> |
|| ||Jan Kara <jack-AT-suse.cz>, Steven Rostedt <rostedt-AT-goodmis.org>,
Ingo Molnar <mingo-AT-elte.hu>,
Thomas Gleixner <tglx-AT-linutronix.de>,
Li Zefan <lizf-AT-cn.fujitsu.com>,
Peter Zijlstra <a.p. |
|| ||Re: [PATCH 0/18] Allow different tracers to be compiled independently |
|| ||Tue, 23 Mar 2010 02:04:21 +0100|
|| ||LKML <linux-kernel-AT-vger.kernel.org>|
|| ||Article, Thread
On Tue, Mar 23, 2010 at 01:32:02AM +0100, Jan Kara wrote:
> currently, when one tracer is selected, most of tracepoints for other
> tracers also gets pulled into the kernel. So for example it's not possible
> to enable BLK_DEV_IO_TRACE without polluting slab allocation paths with
> tracepoint checks (see changelog of patch 01). This patch set adds a
> possibility for each set of trace points to be compile-enabled separately.
> The first patch contains the necessary magic in linux/tracepoint.h. Other
> patches just tell tracing framework about correspoding config options
> and possibly introduce them if they did not exist before.
> The patches in this patch set are actually completely independent so
> they can be merged via respective subsystem trees. But changes are rather
> tiny so I don't expect much conflicts...
(Adding more people in Cc)
I don't know. Yeah this first looks like a good idea but once
CONFIG_EVENT_TRACING is enabled, each tracepoint is a lightweight
thing and induce a tiny overhead, probably hard to notice, and
this is going to be even more the case after the jmp label
I liked the fact we had a general tracing kernel once the above
config is selected. And we don't bother telling people that to
use tool X you need CONFIG_EVENT_Y, and you need to rebuild your
I wonder if this is going to be a win.
to post comments)