A few comments:
- The kernel modules will not be include so the page should remove references to kernel tracing. If users don't have it working out of the box have to go to additional steps to enable that functionality it clearly isn't part of the Fedora feature.
- Ok, I'll try to reword this part.
- In the 'benefit' section, are you suggesting official Fedora packages be built with UST support?
- Yes, that's what I'd suggest, if the package maintainer want to. --greenscientist
- How does this compare with systemtap+uprobes that will be included in the kernel for F18? As far as I know, uprobes allows developers/users to do userspace tracing without rebuilding applications, whereas LTTng seems to require a rebuild for UST tracepoints. --jwboyer
- You're right, Josh, there is overlap, but compiled-in UST is much faster to run tracing jobs than pre-v2.0 systemtap. Also, anything rebuilt with UST markers will also be probe-able with systemtap due to a helpful <sys/sdt.h> indirection.
Is anything in the distro compiled with ust tracepoints, so the various viewers can be used out-of-the-box?
- So far, I don't think so. (The packages were added only a couple of weeks ago)
Various packages, including glibc, already contain systemtap markers. Can LTTng use these markers? Should we expect requests to add similar (duplicated) LTTng markers? Or requests to convert systemtap markers to LTTng markers? --Mitr 10:41, 27 July 2012 (UTC)
- Changing existing sys/sdt.h marker applications to use UST would require convincing their upstream. UST is much heavier weight than sys/sdt.h in terms of emitted object code (i.e., in the dormant tracing-off case, UST costs more time/space than the single NOP of sys/sdt.h), so one may expect performance-critical projects to decline this change.
What is the planned long-term roadmap with this, systemtap, and other tracing/performance frameworks? -- notting