A kernel tracing interface
cover A kernel tracing interface
These patches provide a kernel tracing interface called "trace".
The motivation for "trace" is to:
- Provide a simple set of tracing primitives that will utilize the high- performance and low-overhead of relayfs for passing traces data from kernel to user space.
- Provide a common user interface for managing kernel traces.
- Allow for binary as well as ascii trace data.
- Incorporate features from the systemtap runtime that are useful to others.
History- Versions of this code have been submitted for review under a couple of different names. The original submission was called UTT,
it was later re-submitted as GTSC. Christoph Hellwig commented "The
code looks fine ...but the name is just dumb". Following Christoph's advice, I changed the name to simply "Trace".
This patch addresses review comments made by Christoph Hellwig and Mathieu Desnoyers. Changes include the addition of a mutex and synchronization protecting trace state changes (using RCU) and the reduction of the number of exports.
Patches are against 2.6.23-rc4-mm1
Required patches:
1/2 Trace code and documentation
2/2 Relay reset consumed (required for trace's "rewind" feature")
Quoted 22 lines · On Thu, 13 Sep 2007 16:43:09 -0700 David Wilder <[email protected]> wrote:
These patches provide a kernel tracing interface called "trace".
The motivation for "trace" is to:
- Provide a simple set of tracing primitives that will utilize the high- performance and low-overhead of relayfs for passing traces data from kernel to user space.
- Provide a common user interface for managing kernel traces.
- Allow for binary as well as ascii trace data.
- Incorporate features from the systemtap runtime that are useful to others.History- Versions of this code have been submitted for review under a couple of different names. The original submission was called UTT,
it was later re-submitted as GTSC. Christoph Hellwig commented "The
code looks fine ...but the name is just dumb". Following Christoph's advice, I changed the name to simply "Trace".This patch addresses review comments made by Christoph Hellwig and Mathieu Desnoyers. Changes include the addition of a mutex and synchronization protecting trace state changes (using RCU) and the reduction of the number of exports.
Quoted 7 lines
Patches are against 2.6.23-rc4-mm1
Required patches:
1/2 Trace code and documentation
2/2 Relay reset consumed (required for trace's "rewind" feature")Signed-off-by David Wilder <[email protected]>
Well the code looks neat and easy enough to merge.
What exactly is the relationship between this and systemtap and kprobes and all the other tracing things which people are doing?
Quoted 31 lines · Andrew Morton
Quoted 28 lines · On Thu, 13 Sep 2007 16:43:09 -0700 David Wilder <[email protected]> wrote:
These patches provide a kernel tracing interface called "trace".
The motivation for "trace" is to:
- Provide a simple set of tracing primitives that will utilize the high- performance and low-overhead of relayfs for passing traces data from kernel to user space.
- Provide a common user interface for managing kernel traces.
- Allow for binary as well as ascii trace data.
- Incorporate features from the systemtap runtime that are useful to others.History- Versions of this code have been submitted for review under a couple of different names. The original submission was called UTT,
it was later re-submitted as GTSC. Christoph Hellwig commented "The
code looks fine ...but the name is just dumb". Following Christoph's advice, I changed the name to simply "Trace".This patch addresses review comments made by Christoph Hellwig and Mathieu Desnoyers. Changes include the addition of a mutex and synchronization protecting trace state changes (using RCU) and the reduction of the number of exports.
Patches are against 2.6.23-rc4-mm1
Required patches:
1/2 Trace code and documentation
2/2 Relay reset consumed (required for trace's "rewind" feature")
Quoted 8 lines
Quoted 1 line
Signed-off-by David Wilder <[email protected]>Well the code looks neat and easy enough to merge.
What exactly is the relationship between this and systemtap and kprobes and all the other tracing things which people are doing?
The key to the relationship is relay. Systemtap, kprobes, blktrace ,(and others) need the fast user-kernel data hose that relay provides. Trace is a means to simplify and standardize the use of relay. Systemtap adopted this code some time ago in its own runtime. Moving this code into the kernel will allow other tracers to take advantage of the same trace primitives.
Quoted 37 lines · David Wilder
Quoted 35 lines · Andrew Morton
Quoted 30 lines · On Thu, 13 Sep 2007 16:43:09 -0700 David Wilder <[email protected]> wrote:
These patches provide a kernel tracing interface called "trace".
The motivation for "trace" is to:
- Provide a simple set of tracing primitives that will utilize the high-
performance and low-overhead of relayfs for passing traces data from kernel to user space.
- Provide a common user interface for managing kernel traces.
- Allow for binary as well as ascii trace data.
- Incorporate features from the systemtap runtime that are useful to others.History- Versions of this code have been submitted for review under a couple of different names. The original submission was called UTT,
it was later re-submitted as GTSC. Christoph Hellwig commented "The
code looks fine ...but the name is just dumb". Following Christoph's advice, I changed the name to simply "Trace".This patch addresses review comments made by Christoph Hellwig and Mathieu Desnoyers. Changes include the addition of a mutex and synchronization protecting trace state changes (using RCU) and the reduction of the number of exports.
Patches are against 2.6.23-rc4-mm1
Required patches:
1/2 Trace code and documentation
2/2 Relay reset consumed (required for trace's "rewind" feature")Signed-off-by David Wilder <[email protected]>
Quoted 7 lines
Quoted 6 lines
Well the code looks neat and easy enough to merge.
What exactly is the relationship between this and systemtap and kprobes and all the other tracing things which people are doing?
The key to the relationship is relay. Systemtap, kprobes, blktrace ,(and others) need the fast user-kernel data hose that relay provides. Trace is a means to simplify and standardize the use of relay. Systemtap adopted this code some time ago in its own runtime. Moving this code into the kernel will allow other tracers to take advantage of the same trace primitives.
Andrew,
This is part of the effort by the SystemTap team to move pieces of the project that are generic to mainline.
bye,
Vara Prasad
Quoted 2 lines · On Tue, 18 Sep 2007 09:53:03 -0700 Vara Prasad <[email protected]> wrote:
This is part of the effort by the SystemTap team to move pieces of the project that are generic to mainline.
Yeah. It seems to have been reviewed to death. Is it ready to be applied yet?
Quoted 7 lines · * Andrew Morton ([email protected]) wrote:
Quoted 2 lines · On Tue, 18 Sep 2007 09:53:03 -0700 Vara Prasad <[email protected]> wrote:
This is part of the effort by the SystemTap team to move pieces of the project that are generic to mainline.
Yeah. It seems to have been reviewed to death. Is it ready to be applied yet?
I would just say that this could be seen rather as a driver tracing interface than a general purpose tracing interface. Therefore, maybe the name is a bit misleading ? And yes, what is there is good, but it does not seem to be a replacement for a generic kernel tracer.
My suggestions to turn it into a more suitable interface for a generic tracer are summarized in this email:
http://lkml.org/lkml/2007/9/15/136
Mathieu
Signature · 3 lines
Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
Quoted 12 lines · Mathieu Desnoyers
Quoted 5 lines · * Andrew Morton ([email protected]) wrote:
Quoted 1 line · On Tue, 18 Sep 2007 09:53:03 -0700 Vara Prasad <[email protected]> wrote:
This is part of the effort by the SystemTap team to move pieces of the project that are generic to mainline.
Yeah. It seems to have been reviewed to death. Is it ready to be applied yet?
I would just say that this could be seen rather as a driver tracing interface than a general purpose tracing interface. Therefore, maybe the name is a bit misleading ? And yes, what is there is good, but it does not seem to be a replacement for a generic kernel tracer.
Quoted 6 lines
My suggestions to turn it into a more suitable interface for a generic tracer are summarized in this email:
http://lkml.org/lkml/2007/9/15/136Mathieu
Hi Mathieu
Sorry I did not comment earlier on your email describing a generic
tracer. I believe that "trace" and your generic tracer could complement each other nicely. The trace primitives could be expanded in the future to provide many of the features you described. However, some of the features you describe are dependent on the format of the trace data itself (for example filtering), thus belong in a layer on top of trace.
Dave.
Quoted 7 lines · Andrew Morton
Quoted 1 line · On Tue, 18 Sep 2007 09:53:03 -0700 Vara Prasad <[email protected]> wrote:
This is part of the effort by the SystemTap team to move pieces of the project that are generic to mainline.
Yeah. It seems to have been reviewed to death. Is it ready to be applied yet?
I am just finishing up incorporating your review comments. I hope to have a new patch out by end.
Thanks for the support
Dave.