Re: tracepoint maintainance models

[Michel Dagenais <michel.dagenais@polymtl.ca>]

> ... I don't understand why LTT and SystemTap can't just
> merge and play nice together....

For simple userland tasks, GDB might be all one needs. In other cases,
strace is less intrusive. Yet, in many occasions, the problem is not
reproducible under strace because the timing is changed and a better
mechanism is needed.

Similarly, most sysadmins will be delighted to dynamically activate a
few tracepoints on their live system and catch their problem. In
difficult cases (e.g. distributed application in a large cluster,
embedded systems, nasty problem in the interrupt routine of a device
driver) you need the tool with the lowest disturbance and you will be
ready to recompile and reboot if necessary. If kprobes can achieve this
lowest disturbance (i.e. superior to a static tracepoint in almost all
cases) life will be simpler for all of us.

It does not appear to be the case, however. There are a number of
contexts where kprobes cannot be set (e.g. NMI, m68k :-) and, despite
not having the same reentrancy, its performance is lower than LTTng.
Note that the kprobe performance has improved over the weekend and we
should all be glad of that!

I am looking forward to having the best possible tools, indeed converge
to "merge" and play nice, taking the best parts from each system
(dynamic tracepoints with SystemTap, static tracepoints if needed for
more critical areas, the efficient reentrant per cpu LTTng/Relay
recording infrastructure...).