lkml.org 
[lkml]   [2008]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v10 Golden] Unified trace buffer

On Tue, 30 Sep 2008, Peter Zijlstra wrote:
> >
> > Actually, looking at the code, there is no reason I need to keep this in
> > the frame buffer itself. I've also encapsulated the accesses to the
> > incrementing of the pointers so it would be trivial to try other
> > approaches.
> >
> > The problem we had with the big array struct is that we can want large
> > buffers and to do that with pointers means we would need to either come up
> > with a large allocator or use vmap.
> >
> > But I just realized that I could also just make a link list of page
> > pointers and do the exact same thing without having to worry about page
> > frames. Again, the way I coded this up, it is quite trivial to replace
> > the handling of the pages with other schemes.
>
> The list_head in the page frame should be available regardless of
> splice() stuffs.

Regardless, there's more info we want to store for each page than the list
head. Especially when we start converting this to lockless. I rather get
out of the overlaying of the page frames, its nice to save the space, but
really scares the hell out of me. I can just imagine this blowing up if we
redo the paging, and I dislike this transparent coupling between the
tracer buffer and the pages.

-- Steve



\
 
 \ /
  Last update: 2008-09-30 19:43    [W:0.412 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site