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

Ingo Molnar
2006-09-14T23:28:08Z

* Martin Bligh <mbligh@mbligh.org> 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