Experimental systemtap integrations of LTTng and 'blktrace transport'
Tom Zanussi <[email protected]>
| Newsgroups | gmane.linux.systemtap,gmane.linux.kernel.tracing |
|---|---|
| Message-ID | <[email protected]> |
Hi, Following this mail are two sets of experimental patches, one implementing a first attempt at integrating systemtap with LTTng and the other a first attempt at integrating systemtap with the 'blktrace transport'. The 'blktrace transport' I'm referring to is basically just the non-block-tracing specific kernel and user parts separated out into separate files/config options that anyone can use, not just blktrace. The reason I've provided integrations of both LTTng and the 'blktrace transport' is because systemtap currently has two different needs - a default 'immediate' mode, where probe data is made immediately available to userspace, and a 'bulk' mode which collects as much data as possible in the kernel and then sends it as efficiently as possible to userspace in large blocks. LTTng does the latter very well, as does blktrace (blktrace uses read() while LTTng uses mmap()), but blktrace also has a 'live' mode which can be used to provide the 'immediate' mode needed by systemtap. In addition, LTTng also provides a comprehensive event management/definition system as well as a completely re-entrant logging mechanism, while blktrace adds the ability to do network tracing. The other reason I went through the exercise of doing this is that we've also been asked by the kernel developers to push whatever useful pieces of systemtap infrastructure into the kernel that we can. Systemtap already has a robust transport, which is a combination of a read() based 'immediate' mode based on proc files, and straight relay w/mmap() for 'bulk' mode, and that may indeed be what we want to push into mainline; these experimental patches basically just attempt to replicate the same functionality using existing pieces of tracing infrastructure already in the kernel or presumably soon-to-be in the kernel. Just one note - when separating out the blktrace transport, I had to come up with a name for the common code and named it utt, for 'unified trace transport', in the hope that it might provide a starting point for integrating all the useful parts relevant to a generic tracing transport together. You shouldn't read too much into that name - it may well be that a utt.c ends up coming mainly from LTTng or systemtap and the blktrace stuff merges into that, or it may be that it doesn't make sense to merge anything together, or that there are other better tracing transports that I'm not aware of. Whatever the case, I hope that this code will provide a sandbox for experimenting with these options. Also, standard disclaimer, all this is first cut code, and there are rough edges that could end up crashing your system, so buyer beware. Tom