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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
