Messages in this thread |  | | | Date | Sat, 16 Sep 2006 12:19:03 +0200 | | From | Jes Sorensen <> | | Subject | Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108 |
| |
Andrew Morton wrote: > On Fri, 15 Sep 2006 20:19:07 +0200 > Ingo Molnar <mingo@elte.hu> wrote: > >> * Andrew Morton <akpm@osdl.org> wrote: >> >>> What Karim is sharing with us here (yet again) is the real in-field >>> experience of real users (ie: not kernel developers). >> well, Jes has that experience and Thomas too. > > systemtap and ltt are the only full-scale tracing tools which target > sysadmins and applciation developers of which I am aware..
Just to clarify, the stuff I have looked at in the field was based on LTT, but not part of the official LTT. It simply goes to show that end users cannot agree on a small set of fixed tracepoints because someone always wants a slightly different view of things, like in the cases I looked at. Not to mention that the changes LTT users make, at times, to shoehorn their stuff in, especially in sensitive codepaths such as the syscall path, have side effects which clearly weren't considered.
In one case I ended up doing an alternative implementation using kprobes to prove that similar results could be achieved in that manner. Strangely enough I was right :)
I don't have any objections to markers as Ingo suggested. I just don't buy the repeated argument that LTT has been around for years and barely changed. It's simply a case of the LTT team not being aware (or deciding to ignore, I cannot say which) what users have actually done with the LTT codebase, but it seems obvious they are not aware what everyone is doing with it. But we have seen before how if an infrastructure like LTT goes into the kernel, many more users will pop up and want to have their stuff added.
The other part is the constantly repeated performance claim, which to this point hasn't been backed up by any hard evidence. If we are to take that argument serious, then I strongly encourage the LTT community to present some real numbers, but until then it can be classified as nothing but FUD.
I shall be the first to point out that kprobes are less than ideal, especially the current ia64 implementation suffers from some tricky limitations, but thats an implementation issue.
Cheers, Jes - 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/
|  |