No edit summary |
|||
Line 12: | Line 12: | ||
Is anything in the distro compiled with ust tracepoints, so the various viewers can be used out-of-the-box? | 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) | ** 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? --[[User:Mitr|Mitr]] 10:41, 27 July 2012 (UTC) | 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? --[[User:Mitr|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. | |||
== roadmap == | == roadmap == | ||
What is the planned long-term roadmap with this, systemtap, and other tracing/performance frameworks? -- [[User:notting|notting]] | What is the planned long-term roadmap with this, systemtap, and other tracing/performance frameworks? -- [[User:notting|notting]] |
Revision as of 16:33, 27 July 2012
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.
in-distro users?
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.
roadmap
What is the planned long-term roadmap with this, systemtap, and other tracing/performance frameworks? -- notting