This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH] Linux Kernel Markers
- From: Ingo Molnar <mingo at elte dot hu>
- To: Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, Paul Mundt <lethal at linux-sh dot org>, linux-kernel <linux-kernel at vger dot kernel dot org>, Jes Sorensen <jes at sgi dot com>, Andrew Morton <akpm at osdl dot org>, Tom Zanussi <zanussi at us dot ibm dot com>, Richard J Moore <richardj_moore at uk dot ibm dot com>, Michel Dagenais <michel dot dagenais at polymtl dot ca>, Christoph Hellwig <hch at infradead dot org>, Greg Kroah-Hartman <gregkh at suse dot de>, Thomas Gleixner <tglx at linutronix dot de>, William Cohen <wcohen at redhat dot com>, "Martin J. Bligh" <mbligh at mbligh dot org>, ltt-dev at shafik dot org, systemtap at sources dot redhat dot com, Alan Cox <alan at lxorguk dot ukuu dot org dot uk>
- Date: Tue, 19 Sep 2006 10:11:24 +0200
- Subject: Re: [PATCH] Linux Kernel Markers
- References: <20060918234502.GA197@Krystal>
* Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> +choice
> + prompt "MARK code marker behavior"
> +config MARK_KPROBE
> +config MARK_JPROBE
> +config MARK_FPROBE
> + Change markers for a function call.
> +config MARK_PRINT
as indicated before in great detail, NACK on this profileration of
marker options, especially the function call one. I'd like to see _one_
marker mechanism that distros could enable, preferably with zero (or at
most one NOP) in-code overhead. (You can of course patch whatever
extension ontop of it, in out-of-tree code, to gain further performance
advantage by generating direct system-calls.)
There might be a hodgepodge of methods and tools in userspace to do
debugging, but in the kernel we should get our act together and only
take _one_ (or none at all), and then spend all our efforts on improving
that primary method of debug instrumentation. As kprobes/SystemTap has
proven, it is possible to have zero-overhead inactive probes.
Furthermore, for such a patch to make sense in the upstream kernel,
downstream tracing code has to make actual use of that NOP-marker. I.e.
a necessary (but not sufficient) requirement for upstream inclusion (in
my view) would be for this mechanism to be used by LTT and LKST. (again,
you can patch LTT for your own purposes in your own patchset if you
think the performance overhead of probes is too much)
Ingo