Integrate support for LTTng
Launchpad Entry: https://blueprints.launchpad.net/ubuntu/+spec/other-linaro-n-lttng
We wish to investigate if LTTng kernel patchset can be integrated into Linaro kernel tree.
As of Maverick, Ubuntu has support for the userspace LTTng tools, but the kernel side is an out-of-tree patch. We need to determine if this patch is suitable for inclusion in the Linaro kernel tree, and either integrate it or provide it as a separate kernel tree for those wishing to use this feature.
Merge LTTng upstream git branch (http://git.kernel.org/?p=linux/kernel/git/compudj/linux-2.6-lttng.git) to linux-linaro-next.
- For local testing, create a new branch "for-linaro-next" of LTTng that can be merged cleanly into linux-linaro-next.
- Integrate the LTTng patches into a test kernel package for Ubuntu based on the existing linux-linaro source package in Maverick and cross-build it using the armel cross compiler.
BoF agenda and discussion
- Ongoing plan is to reduce the size of the patchset to allow simpler distro integration.
- LTTng doesn't read performance counters at all currently, uses cycle counter.
- How intrusive is it into the core of the kernel?
- Having it as a module would be preferable.
- Being merged upstream feature by feature; generic ring buffer is being implemented now.
- LTTng tracer will be a separate module always that is a user of that ring buffer.
- Userspace tools (lttctl, ltt-armall etc.) are in PPA, no plans for Ubuntu archive integration currently. Should we integrate it into Linaro?
- ARM specific:
- Takes control of the cycle counter in kernel space; may want to consider some of the tracing-specific stuff that's been done as a generic clock source for the whole kernel.
- Uses only 31 bits of the cycle counter to work around bugs in earlier CPUs (Cortex-A8, incl. omap3, probably Freescale?).
- There is a reservation mechanism for the cycle counter.
- Is this the right interface, or do we need a different architecture in the kernel for sharing this?
- There is a reservation mechanism right now that LTTng doesn't use; LTTng should be switched to use it.
- This percludes the use of both LTTng and perf at the same time, likely they should share a mechanism exposing this common time based via VDSO style interface would be good for the userspace tools as well as good for any tools which read the time a lot like java.
- Backtracing and unwinding is hard on ARM, currently this is not used so should not be an issue. Reasonable to not have backtracing at all on ARM right now; discussion ongoing about using libunwind as the general solution for this.
Platform/DevPlatform/Specs/LTTng (last modified 2011-01-27 07:33:07)