On Fri, 2006-09-15 at 01:19 +0200, Ingo Molnar wrote:
> 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.
Another interesting idea would be the addition to gcc of a:
__builtin_trace_point(char *name, ...)
It would output a function call sized NOP at it's call site, and store
in another section the trace point name, location, and (this is the
important part) a series of DWARF expressions to reconstruct the trace
point's argument list from the stack frame and saved registers.
This would completely eliminate the argument passing overhead of a
patched-out function call in the cases where the trace point takes
arguments.
It'd also make your __trace function attribute unnecessary, because gcc
could presumably figure out that the trace point is at the beginning of
the function.
It "only" requires compiler support on every architecture that the
kernel cares about and compiler upgrades for everyone who wants to use
static trace points, which is no mean feat.
(Roman Zippel was trimmed from the CC list because his server is
rejecting mail from me and/or Comcast. If the first attempts actually
make it through and this is yet another duplicate, sorry.)
--
Nicholas Miell <[email protected]>
-
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]
