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

["Martin J. Bligh" <mbligh@mbligh.org>]

> 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);

Personally I think that's way more visually offensive that something
that looks like a function call, but still ;-) We do it as a caps macro

KTRACE(foo, bar)

internally, which I suppose makes it not look like a function call.
But at the end of the day, it's all just a matter of visual taste,
what's actually in there is way more important.

> 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.

Yup, sometimes you just want to know when a function is called, and
there's no real need to add that. The hook for system calls should be
pretty generic too. But things like instrumenting the reclaim code need
more work - I ended up incrementing some counters for each type of page
recovery failure in shrink_list() and then just logging one compound
event on the stats structure at the end. That's pretty specific, but
does give you a lot of useful data when the box is dying from mem
pressure.

> > 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.

I have to figure out how to graft the internal Google stuff onto the
same mechanism ... I definitely want to be able to combine the static
points with dynamic ones. And then add schedstats and blktrace into
the same thing so it interleaves properly ... seeing the blktrace type
data interact with memory reclaim debugging was very useful to me, for
instance. All these little fragmented tools are way more difficult to
deal with.

M.

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