[PATCH 0/2] A kernel tracing interface

[PATCH 0/2] A kernel tracing interface

[David Wilder]

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 <dwilder@us.ibm.com>

Re: [PATCH 0/2] A kernel tracing interface

[Andrew Morton]

On Thu, 13 Sep 2007 16:43:09 -0700
David Wilder <dwilder@us.ibm.com> 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 <dwilder@us.ibm.com>

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?

Re: [PATCH 0/2] A kernel tracing interface

[David Wilder]

Andrew Morton wrote:
> On Thu, 13 Sep 2007 16:43:09 -0700
> David Wilder <dwilder@us.ibm.com> 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 <dwilder@us.ibm.com>
> 
> 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.

Re: [PATCH 0/2] A kernel tracing interface

[Vara Prasad]

David Wilder wrote:

> Andrew Morton wrote:
>
>> On Thu, 13 Sep 2007 16:43:09 -0700
>> David Wilder <dwilder@us.ibm.com> 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 <dwilder@us.ibm.com>
>>
>>
>> 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

Re: [PATCH 0/2] A kernel tracing interface

[Andrew Morton]

On Tue, 18 Sep 2007 09:53:03 -0700 Vara Prasad <prasadav@us.ibm.com> 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?

Re: [PATCH 0/2] A kernel tracing interface

[Mathieu Desnoyers]

* Andrew Morton (akpm@linux-foundation.org) wrote:
> On Tue, 18 Sep 2007 09:53:03 -0700 Vara Prasad <prasadav@us.ibm.com> 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

Re: [PATCH 0/2] A kernel tracing interface

[David Wilder]

Mathieu Desnoyers wrote:
> * Andrew Morton (akpm@linux-foundation.org) wrote:
>> On Tue, 18 Sep 2007 09:53:03 -0700 Vara Prasad <prasadav@us.ibm.com> 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.

Re: [PATCH 0/2] A kernel tracing interface

[David Wilder]

Andrew Morton wrote:
> On Tue, 18 Sep 2007 09:53:03 -0700 Vara Prasad <prasadav@us.ibm.com> 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.