Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

[Ingo Molnar <mingo@elte.hu>]

* Roman Zippel <zippel@linux-m68k.org> wrote:

> Hi,
> 
> On Thu, 14 Sep 2006, Ingo Molnar wrote:
> 
> > > On Thu, 14 Sep 2006, Ingo Molnar wrote:
> > > 
> > > > i have one very fundamental question: why should we do this 
> > > > source-intrusive method of adding tracepoints instead of the dynamic, 
> > > > unintrusive (and thus zero-overhead) KProbes+SystemTap method?
> > > 
> > > Could you define "zero-overhead"?
> > 
> > zero overhead when not used: not a single instruction added to the 
> > kernel codepath that is to be traced, anywhere. (which will be the case 
> > on 99% of the systems)
> 
> Using alternatives this could be near zero as well and it will likely 
> have less overhead when it's actually used.

if there are lots of tracepoints (and the union of _all_ useful 
tracepoints that i ever encountered in my life goes into the thousands) 
then the overhead is not zero at all.

also, the other disadvantages i listed very much count too. Static 
tracepoints are fundamentally limited because:

  - they can only be added at the source code level

  - modifying them requires a reboot which is not practical in a
    production environment

  - there can only be a limited set of them, while many problems need
    finegrained tracepoints tailored to the problem at hand

  - conditional tracepoints are typically either nonexistent or very
    limited.

for me these are all _independent_ grounds for rejection, as a generic 
kernel infrastructure.

> > the key point is that we want _zero_ "static tracepoints". Firstly, 
> > static tracepoints are fundamentally limited:
> 
> BTW I don't mind KProbes as an option, but I have huge problem with 
> making it the only option.

i'm not arguing for SystemTap to be the only option (KProbes is just the 
infrastructure SystemTap is using - there are other uses for KProbes 
too), but i'm arguing against the inclusion of static tracepoints as an 
infrastructure, precisely because a much better option (SystemTap) is 
already available and is usable on the stock kernel. You are of course 
free to invent other, equally advantageous (or better) options.

> > But besides the usability problems, the most important problem is 
> > that static tracepoints add a _constant maintainance overhead_ to 
> > the kernel. I'm talking from first hand experience: i wrote 
> > 'iotrace' (a static tracer) in 1996 and have maintained it for many 
> > years, and even today i'm maintaining a handful of tracepoints in 
> > the -rt kernel. I _dont_ want static tracepoints in the mainline 
> > kernel.
> 
> Even dynamic tracepoints have a maintainance overhead and I doubt 
> there is much difference. The big problem is having to maintain them 
> outside the mainline kernel, that's why it's so important to get them 
> into the mainline kernel.

i dispute that: for example kernel/sched.c has zero maintainance 
overhead under SystemTap, while it's nonzero with static tracepoints. Of 
course SystemTap _itself_ has maintainance overhead, but it does not 
slow down any other subsystem's speed of progress.

> You didn't address my main issue at all - kprobes is only available 
> for a few archs...

the kprobes infrastructure, despite being fairly young, is widely 
available: powerpc, i386, x86_64, ia64 and sparc64. The other 
architectures are free to implement them too, there's nothing 
hardware-specific about kprobes and the "porting overhead" is in essence 
a one-time cost - while for static tracepoints the maintainance overhead 
goes on forever and scales linearly with the number of tracepoints 
added.

	Ingo