+++ /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>
-
-
-
--- /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>
+
+
+
--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+ <title>Current status</title>
+</head>
+ <body>
+
+<h1>Current status</h1>
+
+<p>
+As of january 28 2004, the Linux Trace Toolkit viewer is nearing feature
+completeness for the first release. A few features need some additional work.
+Thereafter, polishing, stabilizing, and documentation will take place before
+adding new features. It can be considered pre alpha but usable for displaying
+detailed event lists. Furthermore, it may be used to plan the development of
+new modules for the viewer.
+
+The underlying libltt library is fairly stable and mature. It may be considered
+alpha.
+<P>
+
+</body>
+</html>
+
+
+
--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+ <title>Roadmap</title>
+</head>
+ <body>
+
+<h1>Roadmap</h1>
+
+<p>
+As of january 28 2004, the short term development plans include the following
+items.
+
+<UL>
+<LI> Add the copyright notices in each program file.
+<LI> Insure that the coding practices are being implemented.
+<LI> Polish the visual appearance: icons for the tabs and buttons,
+ background, lines and labels in the control flow viewer...
+<LI> When a trace is opened, start a background thread to precompute
+ the system state and memorize it after each ~100 000 events.
+ Have the option to save the precomputed state when a trace is closed.
+ Use the precomputed state if available when opening a trace or
+ seeking in a trace. Use the same thread for computing statistics.
+<LI> Update module.c to ease changing a module into a builtin feature.
+<LI> Split processTrace into tracecontext and processtrace.
+<LI> Insure that g_info logging is generally available but off by default.
+<LI> Document each header file such that developer documentation can
+ be extracted automatically using
+ <A href="http://www.doxygen.org">Doxygen</A>.
+<LI> Complete the user and developer documentation.
+<LI> Test the viewer on large SMP traces. Insure that 2GB files do not cause
+ crashes. Note and fix unduly long delays.
+<LI> Add C99 test (declaration of variable inside a function) to configure.in
+
+
+</body>
+</html>
+
+
+
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <title>Current status</title>
-</head>
- <body>
-
-<h1>Current status</h1>
-
-<p>
-As of january 28 2004, the Linux Trace Toolkit viewer is nearing feature
-completeness for the first release. A few features need some additional work.
-Thereafter, polishing, stabilizing, and documentation will take place before
-adding new features. It can be considered pre alpha but usable for displaying
-detailed event lists. Furthermore, it may be used to plan the development of
-new modules for the viewer.
-
-The underlying libltt library is fairly stable and mature. It may be considered
-alpha.
-<P>
-
-</body>
-</html>
-
-
-
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <title>Roadmap</title>
-</head>
- <body>
-
-<h1>Roadmap</h1>
-
-<p>
-As of january 28 2004, the short term development plans include the following
-items.
-
-<UL>
-<LI> Add the copyright notices in each program file.
-<LI> Insure that the coding practices are being implemented.
-<LI> Polish the visual appearance: icons for the tabs and buttons,
- background, lines and labels in the control flow viewer...
-<LI> When a trace is opened, start a background thread to precompute
- the system state and memorize it after each ~100 000 events.
- Have the option to save the precomputed state when a trace is closed.
- Use the precomputed state if available when opening a trace or
- seeking in a trace. Use the same thread for computing statistics.
-<LI> Update module.c to ease changing a module into a builtin feature.
-<LI> Split processTrace into tracecontext and processtrace.
-<LI> Insure that g_info logging is generally available but off by default.
-<LI> Document each header file such that developer documentation can
- be extracted automatically using
- <A href="http://www.doxygen.org">Doxygen</A>.
-<LI> Complete the user and developer documentation.
-<LI> Test the viewer on large SMP traces. Insure that 2GB files do not cause
- crashes. Note and fix unduly long delays.
-<LI> Add C99 test (declaration of variable inside a function) to configure.in
-
-
-</body>
-</html>
-
-
-
projects / lttv.git / commitdiff
