Messages in this thread | | | Subject | Re: tracepoint maintainance models | From | Michel Dagenais <> | Date | Mon, 18 Sep 2006 16:12:16 -0400 |
| |
> ... 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...).
- 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/
| |