Messages in this thread | | | Date | Fri, 23 Jul 2004 18:40:26 -0400 (EDT) | Subject | Re: LTT user input | From | Robert Wisniewski <> |
| |
Roger Luethi writes: > On Fri, 23 Jul 2004 12:34:19 -0500, zanussi@us.ibm.com wrote: > > I agree that it would make sense for all these tools to at least share > > a common set of hooks in the kernel; it would be great if a single > > framework could serve them all too. The question at the summit was > > 'why not use the auditing framework for tracing?'. I haven't had a > > chance to look much at the code, but the performance numbers published > > for tracing syscalls using the auditing framework aren't encouraging > > for an application as intensive as tracing the entire system, as LTT > > does. > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=107826445023282&w=2 > > Looking for a common base was certainly easier before one tracing > framework got merged. I don't claim to know if a common basic framework > would be beneficial, but I am somewhat amazed that not more effort has > gone into exploring this.
Argh. I had up to this point been passively following this thread because a while ago, prior to dtrace and other such work I, Karim, and others invested quite of bit of effort and time responding to this group pointing out the benefits of performance monitoring via tracing and
IN FACT this was exactly one of the points I ardently made. Having each subsystem set up their own monitoring was not only counter productive in terms of time and implementation effort, but prevented a unified view of performance from being achieved. Nevertheless, it appears that some subsystem tracing has been incorporated, though tbh I have not followed as closely recently.
LTT and relayfs offered the best performing, most comprehensive solution, and was reasonably unintrusive. The work was integrated with dprodes, allowing dynamic insertion and the zero cost non-monitored overhead proclaimed by dtrace. As Karim has pointed out in previous posts, though the technical concerns that were raised were addressed, it didn't seem to help as other nits would crop up appearing to imply that something else was happening. If indeed the remaining issue is whether there is a benefit to a performance monitoring infrastructure, then I wonder how you would interpret reactions to dtrace.
Robert Wisniewski The K42 MP OS Project IBM T.J. Watson Research Center http://www.research.ibm.com/K42/
- 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/
| |