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

[Ingo Molnar]

* Martin Bligh <mbligh@xxxxxxxxxx> wrote:

> > note that such a limited, minimally invasive 'data extraction point' 
> > infrastructure is not actually what the LTT patches are doing. It's 
> > not even close, and i think you'll be surprised. Let me quote from 
> > the latest LTT patch (patch-2.6.17-lttng-0.5.108, which is the same 
> > version submitted to lkml - although no specific tracepoints were 
> > submitted):
> 
> OK, I grant you that's pretty scary ;-) However, it's not the only way 
> to do it. Most things we're using write a statically sized 64-bit 
> event into a relayfs buffer, with a timestamp, a minor and major event 
> type, and a byte of data payload.

oh, no need to tell me. I wrote ktrace 10 years ago, iotrace 8 years ago 
and latency-trace 2 years ago. (The latter even does extensive mcount 
based tracing, which is as demanding on the ringbuffer as it gets - on 
my testbox i routinely get 10-20 million trace events per second, where 
each trace entry includes: type, cpu, flags, preempt_count, pid, 
timestamp and 4 words of arbitrary payload, all fit into 32 bytes. It 
has static tracepoints too, in addition to the 20,000-40,000 mcount 
tracepoints a typical kernel has.)

So i think i know the advantages and disadvantages of static tracers, 
their maintainance and performance impact.

but i think (and i think now you'll be surprised) the way to go is to do 
all this in SystemTap ;-) If we add any static points to the kernel then 
it should have a pure 'local data preparation for extraction' purpose - 
nothing more. Static tracing can be built around that too, but at that 
point it will be unnecessary because SystemTap will be able to do that 
too, with the same (or better, considering the LTT mess) performance.

i.e. we should have macros to prepare local information, with macro 
arities of 2, 3, 4 and 5:

    _(name, data1);
   __(name, data1, data2);
  ___(name, data1, data2, data3);
 ____(name, data1, data2, data3, data4);

that and nothing more. But no guarantees that these trace points will 
always be there and usable for static tracers: for example about 50% of 
all tracepoints can be eliminated via a function attribute. (which 
function attribute tells GCC to generate a 5-byte NOP as the first 
instruction of the function prologue.) That will be invariant to things 
like function renames, etc.

> So perhaps it'll all work. Still need a little bit of data maintained 
> in tree though.

ok. And i think SystemTap itself should be in tree too, with a couple of 
examples and helper scripts all around tracing and probing - and of 
course an LTT-compatible trace output so that all the nice LTT userspace 
code and visualization can live on.

	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/