lkml.org 
[lkml]   [2008]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 1/3] Unified trace buffer
On Sat, 27 Sep 2008, Peter Zijlstra wrote:

> On Sat, 2008-09-27 at 13:38 -0400, Steven Rostedt wrote:
>
> > It does not even implement the merge sort. That's up to the
> > tracer to handle.
>
> You could though, as you have the timestamps..

Yep, and the first version did just that. I could add it back, but it gets
interesting if we want to read from a buffer not on the same CPU, if we
want to implement lockless.

I started (but pushed it aside) a tracing_buffer.c layer, that would do
the merges and such based on the timestamps, as well as events and event
registration. It was because of you that I pulled this stuff out of the
bottom ring buffer layer ;-)


>
> > So yes, the tracer can implement anything it wants on top of the ring
> > buffer ;-)
>
> Mathieu seems to disagree, it would be good if he can share some
> specifics so we can work on resolving those.

Mathieu always disagrees ;-)

Well the ring buffer interface should never interact directly with the
user interface. There should always be a layer between the buffer and the
user interface. This means that V2 can change drastically from V1. But I
want V1 to get in now so that we can start unifying the existing tracers
in the kernel.

Also, I like Linus's proposal that anything bigger than a page needs to be
kept outside the ring buffer and the ring buffer can simply add a pointer
to it.

-- Steve



\
 
 \ /
  Last update: 2008-09-27 20:21    [W:0.073 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site