Commit | Line | Data |
---|---|---|
720c9a06 MD |
1 | Please contact Mathieu Desnoyers <mathieu.desnoyers@efficios.com> for |
2 | questions about this TODO list. The "Cleanup/Testing" section would be | |
3 | good to go through before integration into mainline. The "Features" | |
4 | section is a wish list of features to complete before releasing the | |
5 | "LTTng 2.0" final version, but are not required to have LTTng working. | |
6 | These features are mostly performance enhancements and instrumentation | |
7 | enhancements. | |
8 | ||
9 | TODO: | |
10 | ||
11 | A) Cleanup/Testing | |
12 | ||
13 | 1) Remove debugfs "lttng" file (keep only procfs "lttng" file). | |
14 | The rationale for this is that this file is needed for | |
15 | user-level tracing support (LTTng-UST 2.0) intended to be | |
16 | used on production system, and therefore should be present as | |
17 | part of a "usually mounted" filesystem rather than a debug | |
18 | filesystem. | |
19 | ||
20 | 2) Test lib ring buffer snapshot feature. | |
21 | When working on the lttngtop project, Julien Desfossez | |
22 | reported that he needed to push the consumer position | |
23 | forward explicitely with lib_ring_buffer_put_next_subbuf. | |
24 | This means that although the usual case of pairs of | |
25 | lib_ring_buffer_get_next_subbuf/lib_ring_buffer_put_next_subbuf | |
26 | work fine, there is probably a problem that needs to be | |
27 | investigated in | |
28 | lib_ring_buffer_get_subbuf/lib_ring_buffer_put_subbuf, which | |
29 | depend on the producer to push the reader position. | |
30 | Contact: Julien Desfossez <julien.desfossez@polymtl.ca> | |
31 | ||
32 | ||
33 | B) Features | |
34 | ||
35 | 1) Integration of the LTTng 0.x trace clocks into | |
36 | LTTng 2.0. | |
37 | Currently using mainline kernel monotonic clock. NMIs can | |
38 | therefore not be traced, and this causes a significant | |
39 | performance degradation compared to the LTTng 0.x trace | |
40 | clocks. Imply the creation of drivers/staging/lttng/arch to | |
41 | contain the arch-specific clock support files. | |
42 | * Dependency: addition of clock descriptions to CTF. | |
43 | See: http://git.lttng.org/?p=linux-2.6-lttng.git;a=summary | |
44 | for the LTTng 0.x git tree. | |
45 | ||
46 | 2) Port OMAP3 LTTng trace clocks to x86 to support systems | |
47 | without constant TSC. | |
48 | * Dependency: (B.1) | |
49 | See: http://git.lttng.org/?p=linux-2.6-lttng.git;a=summary | |
50 | for the LTTng 0.x git tree. | |
51 | ||
52 | 3) Implement mmap operation on an anonymous file created by a | |
53 | LTTNG_KERNEL_CLOCK ioctl to export data to export | |
54 | synchronized kernel and user-level LTTng trace clocks: | |
55 | with: | |
56 | - shared per-cpu data, | |
57 | - read seqlock. | |
58 | The content exported by this shared memory area will be | |
59 | arch-specific. | |
60 | * Dependency: (B.1) && (B.2) | |
61 | See: http://git.lttng.org/?p=linux-2.6-lttng.git;a=summary | |
62 | for the LTTng 0.x git tree, which has vDSO support for | |
63 | LTTng trace clock on the x86 architecture. | |
64 | ||
65 | 3) Integrate the "statedump" module from LTTng 0.x into LTTng | |
66 | 2.0. | |
67 | * Dependency: addition of "dynamic enumerations" type to CTF. | |
68 | See: http://git.lttng.org/?p=lttng-modules.git;a=shortlog;h=refs/heads/v0.19-stable | |
69 | ltt-statedump.c | |
70 | ||
71 | 4) Generate system call TRACE_EVENT headers for all | |
72 | architectures (currently done: x86 32/64). | |
73 | ||
74 | 5) Define "unknown" system calls into instrumentation/syscalls | |
75 | override files / or do SYSCALL_DEFINE improvements to | |
76 | mainline kernel to allow automatic generation of these | |
77 | missing system call descriptions. | |
78 | ||
79 | 6) Create missing tracepoint event headers files into | |
80 | instrumentation/events from headers located in | |
81 | include/trace/events/. Choice: either do as currently done, | |
82 | and copy those headers locally into the lttng driver and | |
83 | perform the modifications locally, or push TRACE_EVENT API | |
84 | modification into mainline headers, which would require | |
85 | collaboration from Ftrace/Perf maintainers. | |
86 | ||
87 | 7) Poll: implement a poll and/or epoll exclusive wakeup scheme, | |
88 | which contradicts POSIX, but protect multiple consumer | |
89 | threads from thundering herd effect. | |
90 | ||
91 | 8) Re-integrate sample modules from libringbuffer into | |
92 | lttng driver. Those modules can be used as example of how to | |
93 | use libringbuffer in other contexts than LTTng, and are | |
94 | useful to perform benchmarks of the ringbuffer library. | |
95 | See: http://www.efficios.com/ringbuffer | |
96 | ||
97 | 9) NOHZ support for lib ring buffer. NOHZ infrastructure in the | |
98 | Linux kernel does not support notifiers chains, which does | |
99 | not let LTTng play nicely with low power consumption setups | |
100 | for flight recorder (overwrite mode) live traces. One way to | |
101 | allow integration between NOHZ and LTTng would be to add | |
102 | support for such notifiers into NOHZ kernel infrastructure. | |
103 | ||
104 | 10) Turn drivers/staging/lttng/ltt-probes.c probe_list into a | |
105 | hash table. Turns O(n^2) trace systems registration (cost | |
106 | for n systems) into O(n). (O(1) per system) | |
107 | ||
108 | 11) drivers/staging/lttng/probes/lttng-ftrace.c: | |
109 | LTTng currently uses kretprobes for per-function tracing, | |
110 | not the function tracer. So lttng-ftrace.c should be used | |
111 | for "all" function tracing. | |
112 | ||
113 | 12) drivers/staging/lttng/probes/lttng-types.c: | |
114 | This is a currently unused placeholder to export entire C | |
115 | type declarations into the trace metadata, e.g. for support | |
116 | of describing the layout of structures/enumeration mapping | |
117 | along with syscall entry events. The design of this support | |
118 | will likely change though, and become integrated with the | |
119 | TRACE_EVENT support within lttng, by adding new macros, and | |
120 | support for generation of metadata from these macros, to | |
121 | allow description of those compound types/enumerations. | |
122 | ||
123 | Please send patches | |
124 | To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |