Re: [PATCH 0/18] Allow different tracers to be compiled independently
[Posted March 24, 2010 by jake]
| From: |
| Frederic Weisbecker <fweisbec-AT-gmail.com> |
| To: |
| 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. |
| Subject: |
| Re: [PATCH 0/18] Allow different tracers to be compiled independently |
| Date: |
| Tue, 23 Mar 2010 02:04:21 +0100 |
| Cc: |
| LKML <linux-kernel-AT-vger.kernel.org> |
| Archive-link: |
| Article, Thread
|
On Tue, Mar 23, 2010 at 01:32:02AM +0100, Jan Kara wrote:
>
> Hi,
>
> 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...
>
> Honza
(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
optimization patches.
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
kernel, etc...
I wonder if this is going to be a win.
(
Log in to post comments)