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:2.980 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site