+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <title>Linux Trace Toolkit Status</title>
-</head>
- <body>
-
-<h1>Linux Trace Toolkit Status</h1>
-
-<p><i>Last updated July 1, 2003.</i> </p>
-
-<p>During the 2002 Ottawa Linux Symposium tracing BOF, a list of desirable
- features for LTT was collected by Richard Moore. Since then, a lot of infrastructure
- work on LTT has been taking place. This status report aims to track current
- development efforts and the current status of the various features. This
-status page is most certainly incomplete, please send
-any additions and corrections to Michel Dagenais (michel.dagenais at polymtl.ca)</p>
-
-<p>As of this writing, the most active LTT contributors include Karim Yaghmour,
-author and maintainer from opersys.com, Tom Zanussi, Robert Wisniewski,
-Richard J Moore and others from IBM, mainly at the Linux Technology Center,
-XiangXiu Yang, Mathieu Desnoyers, Benoit des Ligneris and Michel Dagenais,
-from the department of Computer Engineering at Ecole Polytechnique de
-Montreal, and Frank Rowand, from Monte Vista.</p>
-
-<h2>Work recently performed</h2>
-
-<p><b>Lockless per cpu buffers:</b> Tom Zanussi of IBM has implemented per CPU lockless buffering, with low
-overhead very fine grained timestamping, and has updated accordingly the
-kernel patch and the trace visualizer except for viewing multiple per CPU
-traces simultaneously. </p>
-
-<p><b>RelayFS:</b> Tom Zanussi has implemented RelayFS, a separate, simple
-and efficient component for moving data between the kernel and user space
-applications. This component is reusable by other projects (printk, evlog,
-lustre...) and removes a sizeable chunk from the current LTT, making each
-piece (relayfs and relayfs-based LTT) simpler, more modular and possibly
-more palatable for inclusion in the standard Linux kernel. Besides LTT on
-RelayFS, He has implemented printk over RelayFS with an automatically
-resizeable printk buffer. </p>
-
-<p><b>New trace format:</b> Karim Yaghmour and Michel Dagenais, with input
-from several LTT contributors, have designed a new trace format to accomodate
-per buffer tracefiles and dynamically defined event types. The new format
-includes both the binary trace format and the event type description format.
-XiangXiu Yang has developed a simple parser for the event type description
-format. This parser is used to generate the tracing macros in the kernel
-(genevent) and to support reading tracefiles in the trace reading library
-(libltt).
-
-<h2>Ongoing work</h2>
-
-<p><b>Libltt:</b> XiangXiu Yang is finishing up an event reading library
-and API which parses event descriptions and accordingly reads traces and
-decodes events. </p>
-
-<p><b>lttv:</b> XiangXiu Yang, Mathieu Desnoyers and Michel Dagenais are
-remodeling the trace visualizer to use the new trace format and libltt API,
-and to allow compiled and scripted plugins, which can dynamically
-add new custom trace analysis functions. </p>
-
-<h2>Planned work</h2>
-
-<p>LTT already interfaces with Dynamic Probes. This feature will need to
-be updated for the new LTT version. </p>
-
-<p>The Kernel Crash Dump utilities is another very interesting complementary
- project. Interfacing it with RelayFS will help implement useful
-flight-recorder like tracing for post-mortem analysis. </p>
-
-<p>User level tracing is available in the current LTT version but requires
-one system call per event. With the new RelayFS based infrastructure, it
-would be interesting to use a shared memory buffer directly accessible from
-user space. Having one RelayFS channel per user would allow an extremely
-efficient, yet secure, user level tracing mechanism. </p>
-
-<p>Sending important events (process creation, event types/facilities
-definitions) to a separate channel could be used to browse traces
-interactively more efficiently. Only this concise trace of important
-events would need to be processed in its entirety, other larger
-gigabyte size traces could be used in random access without requiring
-a first preprocessing pass. A separate channel would also be required
-in case of incomplete traces such as when tracing to a circular buffer
-in "flight recorder" mode; the important events would all be kept
-while only the last buffers of ordinary events would be kept. </p>
-
-<p>Once the visualizer is able to read and display several traces, it
- will be interesting to produce side by side synchronized views
- (events from two interacting machines A and B one above the other)
- or even merged views (combined events from several CPUs in a single
- merged graph). Time differences between interacting systems will
- need to be estimated and somewhat compensated for. </p>
-
-<p>LTT currently writes a <i>proc</i> file at trace start time. This
- file only contains minimal information about processes and
- interrupts names. More information would be desirable for several
- applications (process maps, opened descriptors, content of buffer
- cache). Furthermore, this information may be more conveniently
- gathered from within the kernel and simply written to the trace as
- events at start time. </p>
-
-<h2>New features already implemented since LTT 0.9.5</h2>
-
-<ol>
- <li> Per-CPU Buffering scheme. </li>
- <li> Logging without locking. </li>
- <li> Minimal latency - minimal or no serialisation. (<i>Lockless tracing
-using read_cycle_counter instead of gettimeofday.</i>) </li>
- <li> Fine granularity time stamping - min=o(CPU cycle time),
-max=.05 Gb Ethernet interrupt rate. (<i>Cycle counter being used</i>). </li>
- <li> Random access to trace event stream. (<i>Random access reading
-of events in the trace is already available in LibLTT. However, one first
-pass is required through the trace to find all the process creation events;
-the cost of this first pass may be reduced in the future if process creation
- events are sent to a separate much smaller trace</i>.) </li>
-
-</ol>
-
-<h2>Features being worked on</h2>
-
-<ol>
- <li> Simple wrapper macros for trace instrumentation. (<i>GenEvent</i>)
- </li>
- <li> Easily expandable with new trace types. (<i>GenEvent</i>) </li>
- <li> Multiple buffering schemes - switchable globally or selectable
-by trace client. (<i>Will be simpler to obtain with RelayFS</i>.) </li>
- <li> Global buffer scheme. (<i>Will be simpler to obtain with RelayFS</i>.)
- </li>
- <li> Per-process buffer scheme. (<i>Will be simpler to obtain with RelayFS.</i>)
- </li>
- <li> Per-NGPT thread buffer scheme. (<i>Will be simpler to obtain with
- RelayFS</i>.) </li>
- <li> Per-component buffer scheme. (<i>Will be simpler to obtain with
-RelayFS</i>.) </li>
- <li> A set of extensible and modular performance analysis post-processing
-programs. (<i>Lttv</i>) </li>
- <li> Filtering and selection mechanisms within formatting utility. (<i>Lttv</i>)
- </li>
- <li> Variable size event records. (<i>GenEvent, LibEvent, Lttv</i>)
- </li>
- <li> Data reduction facilities able to logically combine traces from
- more than one system. (<i>LibEvent, Lttv</i>) </li>
- <li> Data presentation utilities to be able to present data from multiple
- trace instances in a logically combined form (<i>LibEvent, Lttv</i>)
- </li>
- <li> Major/minor code means of identification/registration/assignment.
- (<i>GenEvent</i>) </li>
- <li> A flexible formatting mechanism that will cater for structures
-and arrays of structures with recursion. (<i>GenEvent</i>) </li>
-
-</ol>
-
-<h2>Features already planned for</h2>
-
-<ol>
- <li> Init-time tracing. (<i>To be part of RelayFS</i>.) </li>
- <li>Updated interface for Dynamic Probes. (<i>As soon as things stabilize.</i>)
- </li>
- <li> Support "flight recorder" always on tracing with minimal resource
-consumption. (<i>To be part of RelayFS and interfaced to the Kernel crash
-dump facilities.)</i> </li>
- <li> Fine grained dynamic trace instrumentation for kernel space and
-user subsystems. (<i>Dynamic Probes, more efficient user level tracing.</i>)</li>
- <li>System information logged at trace start. (<i>New special events
-to add</i>.)</li>
- <li>Collection of process memory map information at trace start/restart
- and updates of that information at fork/exec/exit. This allows address-to-name
- resolution for user space. </li>
- <li>Include the facility to write system snapshots (total memory layout
- for kernel, drivers, and all processes) to a file. This is required for
- trace post-processing on a system other than the one producing the trace.
- Perhaps some of this is already implemented in the Kernel Crash Dump.</li>
- <li>Even more efficient tracing from user space.</li>
- <li>Better integration with tools to define static trace hooks.</li>
- <li> Better integration with tools to dynamically activate tracing statements.</li>
-
-</ol>
-
-<h2>Features not currently planned</h2>
-
-<ol>
- <li>POSIX Tracing API compliance. </li>
- <li>Ability to do function entry/exit tracing facility. (<i>Probably
- a totally orthogonal mechanism using either Dynamic Probes hooks or static
- code instrumentation using the suitable GCC options for basic blocks instrumentation.</i>)</li>
- <li>Processor performance counter (which most modern CPUs have) sampling
-and recording. (<i>These counters can be read and their value sent in traced
-events. Some support to collect these automatically at specific state change
-times and to visualize the results would be nice.)</i></li>
- <li>Suspend & Resume capability. (<i>Why not simply stop the
- trace and start a new one later, otherwise important information like process
-creations while suspended must be obtained in some other way.</i>)</li>
- <li>Per-packet send/receive event. (<i>New event types will be easily
-added as needed.)</i></li>
-
-</ol>
- <br>
- <br>
-
-</body>
-</html>
-
-
-
projects / lttv.git / blobdiff