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

[Ingo Molnar]

* Martin Bligh <mbligh@xxxxxxxxxx> wrote:

> > primarily because i fail to see any property of static tracers that 
> > are not met by dynamic tracers. So to me dynamic tracers like 
> > SystemTap are a superset of static tracers.
> 
> 1. They're harder to maintain out of tree.

as i mentioned before, SystemTap should be in tree. Relayfs was added 
for the sake of SystemTap for example, i have no problem with moving 
SystemTap into the tree either.

> 2. they're written in some jibberish awk crap

You can write embedded-C SystemTap scripts too. There's an "EMBEDDED C" 
section in "man stap".

> 3. They're slower. If you're doing thousands of tracepoints a second,
> 	into a circular 8GB log buffer, that *does* matter. You want
> 	to peturb what you're measuring as little as possible.

i very much agree that they should become as fast as possible. So to 
rephrase the question: can we make dynamic tracepoints as fast (or 
nearly as fast) as static tracepoints? If yes, should we care about 
static tracers at all?

> >So my position is that what we should concentrate on is to make the life 
> >of dynamic tracers easier (be that a handful of generic, parametric 
> >hooks that gather debuginfo information and add NOPs for easy patching), 
> >while realizing that static tracers have no advantage over dynamic 
> >tracers.
> 
> I'm confused. You're saying that the dynamic tracers need help by 
> adding some static data to the kernel, and yet at the same time 
> rejecting static additions to the kernel on the grounds they have no 
> value???

no. I'm saying that dynamic tracers are fundamentally more advanced, and 
that _iff_ we are to add static info to the kernel we should add it _for 
the sole sake of speeding up dynamic tracers_. If static tracers can 
live off the same hooks then fine, but we should architect primarily for 
the needs of the dynamic tracers.

> Perhaps we're just meaning different things by static tracing. To me, 
> what is important is that there is a well-defined place in the source 
> code where the data needed to be logged, and the exact place to log it 
> at, is defined. If all that macro does to the compilation is add a 
> couple of nops, and make an entry in a symbol data, or other debug 
> data, for something to hook into later that's *fine*. The point is to 
> maintain the location and intelligence about *what* to trace.

ok. For me 'static tracepoints' are like the sort of stuff that LTT 
adds: funky function names littering the tree.

i see the point behind 'data extraction point' hooks mentioned by you as 
a compromise, which incidentally will also speed up dynamic tracepoints 
to the level of static tracepoints. But they should be very much 
constructed as data extraction points for the purposes of dynamic 
tracers. (which the LTT hooks currently are not)

> If we want it to be superfast, we could compile with a different 
> config option to insert some tracing statically in there or something, 
> but I agree it should not be the default.

for a dynamic tracer all that is needed is a 5-byte NOP (even on 
64-bit), and the availability of all the data. Maybe even a function 
call that can be patched out after bootup, with NOPs. But the current 
LTT stuff has lots of inlined crap that just bloats the kernel.

> >i.e. why add infrastructure for the sake of something that is clearly 
> >inferior? I have no problem with adding infrastructure for SystemTap, 
> >but i am asking the question: is it worth adding a static tracer?
> 
> Yes ;-) Realise that your usage model is not exactly the same as 
> everyone else's, and I don't give a damn if I have to recompile. I 
> realise other people do, but ....

So you dont care about recompiling: that's fine - but others care, so as 
long as all your needs are met (which we are working on meeting :-) then 
we'll go for the solution that is better - instead of having some dual 
debugging infrastructure.

> > (Just like i would accept the reintroduction of the Big Kernel Lock
> >  too, if someone proved it that it's the right thing to do.)
> 
> Surely it's still there at the moment? ;-)

no - at least for me it's the Big Kernel Semaphore ;-)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/