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]>
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]>
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?
Andrew Morton wrote:
> 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]>
>
> 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.
David Wilder wrote:
> Andrew Morton wrote:
>
>> 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]>
>>
>>
>> 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
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?
* Andrew Morton ([email protected]) wrote:
> 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
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
Andrew Morton wrote:
> 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.
Mathieu Desnoyers wrote:
> * Andrew Morton ([email protected]) wrote:
>> 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
>
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.