|
@@ -0,0 +1,137 @@
|
|
|
+Please contact Mathieu Desnoyers <mathieu.desnoyers@efficios.com> for
|
|
|
+questions about this TODO list. The "Cleanup/Testing" section would be
|
|
|
+good to go through before integration into mainline. The "Features"
|
|
|
+section is a wish list of features to complete before releasing the
|
|
|
+"LTTng 2.0" final version, but are not required to have LTTng working.
|
|
|
+These features are mostly performance enhancements and instrumentation
|
|
|
+enhancements.
|
|
|
+
|
|
|
+TODO:
|
|
|
+
|
|
|
+A) Cleanup/Testing
|
|
|
+
|
|
|
+ 1) Remove debugfs "lttng" file (keep only procfs "lttng" file).
|
|
|
+ The rationale for this is that this file is needed for
|
|
|
+ user-level tracing support (LTTng-UST 2.0) intended to be
|
|
|
+ used on production system, and therefore should be present as
|
|
|
+ part of a "usually mounted" filesystem rather than a debug
|
|
|
+ filesystem.
|
|
|
+
|
|
|
+ 2) Cleanup wrappers. The drivers/staging/lttng/wrapper directory
|
|
|
+ contains various wrapper headers that use kallsyms lookups to
|
|
|
+ work around some missing EXPORT_SYMBOL_GPL() in the mainline
|
|
|
+ kernel. Ideally, those few symbols should become exported to
|
|
|
+ modules by the kernel.
|
|
|
+
|
|
|
+ 3) Test lib ring buffer snapshot feature.
|
|
|
+ When working on the lttngtop project, Julien Desfossez
|
|
|
+ reported that he needed to push the consumer position
|
|
|
+ forward explicitely with lib_ring_buffer_put_next_subbuf.
|
|
|
+ This means that although the usual case of pairs of
|
|
|
+ lib_ring_buffer_get_next_subbuf/lib_ring_buffer_put_next_subbuf
|
|
|
+ work fine, there is probably a problem that needs to be
|
|
|
+ investigated in
|
|
|
+ lib_ring_buffer_get_subbuf/lib_ring_buffer_put_subbuf, which
|
|
|
+ depend on the producer to push the reader position.
|
|
|
+ Contact: Julien Desfossez <julien.desfossez@polymtl.ca>
|
|
|
+
|
|
|
+ 4) Test latest -rt kernel support.
|
|
|
+ There has been report of corrupted traces when tracing a
|
|
|
+ 3.0.10-rt27 in the area of access_ok() system call event.
|
|
|
+ Still has to be investigated. Cannot be reproduced with
|
|
|
+ mainline kernel.
|
|
|
+ Contact: Yannick Brosseau <yannick.brosseau@polymtl.ca>
|
|
|
+
|
|
|
+B) Features
|
|
|
+
|
|
|
+ 1) Integration of the LTTng 0.x trace clocks into
|
|
|
+ LTTng 2.0.
|
|
|
+ Currently using mainline kernel monotonic clock. NMIs can
|
|
|
+ therefore not be traced, and this causes a significant
|
|
|
+ performance degradation compared to the LTTng 0.x trace
|
|
|
+ clocks. Imply the creation of drivers/staging/lttng/arch to
|
|
|
+ contain the arch-specific clock support files.
|
|
|
+ * Dependency: addition of clock descriptions to CTF.
|
|
|
+ See: http://git.lttng.org/?p=linux-2.6-lttng.git;a=summary
|
|
|
+ for the LTTng 0.x git tree.
|
|
|
+
|
|
|
+ 2) Port OMAP3 LTTng trace clocks to x86 to support systems
|
|
|
+ without constant TSC.
|
|
|
+ * Dependency: (B.1)
|
|
|
+ See: http://git.lttng.org/?p=linux-2.6-lttng.git;a=summary
|
|
|
+ for the LTTng 0.x git tree.
|
|
|
+
|
|
|
+ 3) Implement mmap operation on an anonymous file created by a
|
|
|
+ LTTNG_KERNEL_CLOCK ioctl to export data to export
|
|
|
+ synchronized kernel and user-level LTTng trace clocks:
|
|
|
+ with:
|
|
|
+ - shared per-cpu data,
|
|
|
+ - read seqlock.
|
|
|
+ The content exported by this shared memory area will be
|
|
|
+ arch-specific.
|
|
|
+ * Dependency: (B.1) && (B.2)
|
|
|
+ See: http://git.lttng.org/?p=linux-2.6-lttng.git;a=summary
|
|
|
+ for the LTTng 0.x git tree, which has vDSO support for
|
|
|
+ LTTng trace clock on the x86 architecture.
|
|
|
+
|
|
|
+ 3) Integrate the "statedump" module from LTTng 0.x into LTTng
|
|
|
+ 2.0.
|
|
|
+ * Dependency: addition of "dynamic enumerations" type to CTF.
|
|
|
+ See: http://git.lttng.org/?p=lttng-modules.git;a=shortlog;h=refs/heads/v0.19-stable
|
|
|
+ ltt-statedump.c
|
|
|
+
|
|
|
+ 4) Generate system call TRACE_EVENT headers for all
|
|
|
+ architectures (currently done: x86 32/64).
|
|
|
+
|
|
|
+ 5) Define "unknown" system calls into instrumentation/syscalls
|
|
|
+ override files / or do SYSCALL_DEFINE improvements to
|
|
|
+ mainline kernel to allow automatic generation of these
|
|
|
+ missing system call descriptions.
|
|
|
+
|
|
|
+ 6) Create missing tracepoint event headers files into
|
|
|
+ instrumentation/events from headers located in
|
|
|
+ include/trace/events/. Choice: either do as currently done,
|
|
|
+ and copy those headers locally into the lttng driver and
|
|
|
+ perform the modifications locally, or push TRACE_EVENT API
|
|
|
+ modification into mainline headers, which would require
|
|
|
+ collaboration from Ftrace/Perf maintainers.
|
|
|
+
|
|
|
+ 7) Poll: implement a poll and/or epoll exclusive wakeup scheme,
|
|
|
+ which contradicts POSIX, but protect multiple consumer
|
|
|
+ threads from thundering herd effect.
|
|
|
+
|
|
|
+ 8) Re-integrate sample modules from libringbuffer into
|
|
|
+ lttng driver. Those modules can be used as example of how to
|
|
|
+ use libringbuffer in other contexts than LTTng, and are
|
|
|
+ useful to perform benchmarks of the ringbuffer library.
|
|
|
+ See: http://www.efficios.com/ringbuffer
|
|
|
+
|
|
|
+ 9) NOHZ support for lib ring buffer. NOHZ infrastructure in the
|
|
|
+ Linux kernel does not support notifiers chains, which does
|
|
|
+ not let LTTng play nicely with low power consumption setups
|
|
|
+ for flight recorder (overwrite mode) live traces. One way to
|
|
|
+ allow integration between NOHZ and LTTng would be to add
|
|
|
+ support for such notifiers into NOHZ kernel infrastructure.
|
|
|
+
|
|
|
+ 10) Turn drivers/staging/lttng/ltt-probes.c probe_list into a
|
|
|
+ hash table. Turns O(n^2) trace systems registration (cost
|
|
|
+ for n systems) into O(n). (O(1) per system)
|
|
|
+
|
|
|
+ 11) drivers/staging/lttng/probes/lttng-ftrace.c:
|
|
|
+ LTTng currently uses kretprobes for per-function tracing,
|
|
|
+ not the function tracer. So lttng-ftrace.c should be used
|
|
|
+ for "all" function tracing.
|
|
|
+
|
|
|
+ 12) drivers/staging/lttng/probes/lttng-types.c:
|
|
|
+ This is a currently unused placeholder to export entire C
|
|
|
+ type declarations into the trace metadata, e.g. for support
|
|
|
+ of describing the layout of structures/enumeration mapping
|
|
|
+ along with syscall entry events. The design of this support
|
|
|
+ will likely change though, and become integrated with the
|
|
|
+ TRACE_EVENT support within lttng, by adding new macros, and
|
|
|
+ support for generation of metadata from these macros, to
|
|
|
+ allow description of those compound types/enumerations.
|
|
|
+
|
|
|
+Please send patches
|
|
|
+To: Greg Kroah-Hartman <greg@kroah.com>
|
|
|
+To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
|