1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
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>
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>
|
