* 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?

* 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?

Revision as of 14:45, 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?

In the 'benefit' section, are you suggesting official Fedora packages be built with UST support?

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)

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)