From Fedora Project Wiki

No edit summary
 
(4 intermediate revisions by 2 users not shown)
Line 3: Line 3:
* 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.
* 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.  
** Ok, I'll try to reword this part.  
*** The current "detailed description" section still covers almost entirely kernel features ("tracepoints", "syscall tracing", "pmu", "kprobes", ...)  Are all of those supported with the proposed lttng 2.0 package subset, without the lttng kernel module?
**** No you are right, they are not available, I've removed these entries.
* In the 'benefit' section, are you suggesting official Fedora packages be built with UST support?
* 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
** 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
* 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.
** 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. [[User:Fche|Fche]] 16:38, 27 July 2012 (UTC)


== in-distro users? ==
== in-distro users? ==


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. [[User:Fche|Fche]] 16:33, 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. [[User:Fche|Fche]] 16:33, 27 July 2012 (UTC)
 
** Comment from upstream (compudj): "agreed for space, disagreed for time. UST probes, when used without the SDT indirection, skip the entire function call, including stack setup" --greenscientist
== 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]]
* perf & lttng have way more overlap with each other than either does with systemtap.  There does not exist a grand unified roadmap that involves any of these projects being deprecated/merged, AFAIK. [[User:Fche|Fche]] 16:37, 27 July 2012 (UTC)
* perf & lttng have way more overlap with each other than either does with systemtap.  There does not exist a grand unified roadmap that involves any of these projects being deprecated/merged, AFAIK. [[User:Fche|Fche]] 16:37, 27 July 2012 (UTC)
** This will be discussed at the Tracing Summit at the Linux Plumbers conference. --greenscientist
== kernel ==
* Wondering if it can mention that the control part support the kernel module if they are installed or the word kernel should no appear at all? --greenscientist

Latest revision as of 17:40, 30 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.
      • The current "detailed description" section still covers almost entirely kernel features ("tracepoints", "syscall tracing", "pmu", "kprobes", ...) Are all of those supported with the proposed lttng 2.0 package subset, without the lttng kernel module?
        • No you are right, they are not available, I've removed these entries.
  • 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. Fche 16:38, 27 July 2012 (UTC)

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. Fche 16:33, 27 July 2012 (UTC)
    • Comment from upstream (compudj): "agreed for space, disagreed for time. UST probes, when used without the SDT indirection, skip the entire function call, including stack setup" --greenscientist

roadmap

What is the planned long-term roadmap with this, systemtap, and other tracing/performance frameworks? -- notting

  • perf & lttng have way more overlap with each other than either does with systemtap. There does not exist a grand unified roadmap that involves any of these projects being deprecated/merged, AFAIK. Fche 16:37, 27 July 2012 (UTC)
    • This will be discussed at the Tracing Summit at the Linux Plumbers conference. --greenscientist

kernel

  • Wondering if it can mention that the control part support the kernel module if they are installed or the word kernel should no appear at all? --greenscientist