[lttng-modules.git] / TODO

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