Re: [PATCH] Linux Markers 0.4 (+dynamic probe loader) for 2.6.17

[Ingo Molnar <mingo@elte.hu>]

* Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> 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.

	Ingo