This is the mail archive of the
mailing list for the systemtap project.
Re: [PATCH] Linux Markers 0.4 (+dynamic probe loader) for 2.6.17
- From: Ingo Molnar <mingo at elte dot hu>
- To: Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>
- Cc: Martin Bligh <mbligh at google dot com>, "Frank Ch. Eigler" <fche at redhat dot com>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, prasanna at in dot ibm dot com, Andrew Morton <akpm at osdl dot org>, 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>, 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>, 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: Thu, 21 Sep 2006 06:46:03 +0200
- Subject: Re: [PATCH] Linux Markers 0.4 (+dynamic probe loader) for 2.6.17
- References: <20060920234517.GA29171@Krystal>
* Mathieu Desnoyers <email@example.com> wrote:
> +menu "Marker configuration"
> +config MARK_SYMBOL
> + bool "Replace markers with symbols"
> + Put symbols in place of markers, useful for kprobe.
> +config MARK_JUMP_CALL
> + bool "Replace markers with a jump over an inactive function call"
> + Put a jump over a call in place of markers.
> +config MARK_JUMP_INLINE
> + bool "Replace markers with a jump over an inline function"
> + Put a jump over an inline function.
This patch still has the fundamental failure of offering 3 annotation
methods instead of offering _one_ annotation method. I mention it again,
distros want to have _one_ method they enable, not: "oh, by the way, LTT
requires MARK_JUMP_CALL, so no matter how low-overhead MARK_SYMBOL is,
you have to enable MARK_JUMP_CALL anyway".
We have to face it, tracing is a very optional infrastructure, thus it
has to be _very low (preferably zero in most cases) overhead when
offered by a kernel binary but kept inactive by the user_ and thus you
/have to/ program on the edge to get it into the upstream kernel.
It wont be easy to achieve this, and you'll have to work with the other
tracing projects (and upstream kernel folks) to get one unified markup
mechanism agreed on, but nevertheless it's possible technologically.
and the only acceptable near-zero-overhead markup scheme proposed so far
(and suggested by me all along) is the symbol based markup method.
Symbol based markup also has the advantage that the coupling between the
kernel and the tracer moves to the symbol space (from the binary
instruction-stream space), and thus the in-kernel implementation of it
becomes alot more flexible. Flexibility of the upstream kernel design is
another thing that we require for 'very optional' features.
Yes, LTT will probably have to embrace kprobes/SystemTap to insert the
tracepoints themselves, but that's the price we get for uniformity, and
that's the price you get for _having the markers maintained upstream_.
If after that point upstream cannot optimize kprobes performance to a
sufficient level, /then/ can we think about /perhaps/ allowing direct
calls generated into the kernel image. But that decision /must/ be
driven by distributions and customers. Until then, kprobes based marking
and tracing will be 'good enough'.
It affects all tracers: SystemTap/LKST has to adapt to such a scheme
too, because currently there's no markup scheme in the kernel. So this
is not something 'against' LTT, but something /for/ a unified landscape
of tracers. (and as i mentioned it before, it will be easy for you to
offer a simple "LTT speedup patch", which distros and the upstream
kernel can consider separately. But it must be /optional/.)
So far i have not seen any real arguments against this simple but
fundamental upstream requirement which i pointed out for v0.1 already.