lkml.org 
[lkml]   [2005]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Merging relayfs?
Steven Rostedt writes:
> On Tue, 2005-07-12 at 11:08 -0500, Tom Zanussi wrote:
> > Steven Rostedt writes:
> > > On Tue, 2005-07-12 at 10:58 -0400, Jason Baron wrote:
> > > > On Mon, 11 Jul 2005, Tom Zanussi wrote:
> > >
> > > > One concern I had regarding relayfs, which was raised previously, was
> > > > regarding its use of vmap,
> > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=110755199913216&w=2 On x86,
> > > > the vmap space is at a premium, and this space is reserved over the entire
> > > > lifetime of a 'channel'. Is the use of vmap really critical for
> > > > performance?
> > >
> > > I believe that (Tom correct me if I'm wrong) the use of vmap was to
> > > allocate a large buffer without risking failing to allocate. Since the
> > > buffer does not need to be in continuous pages. If this is a problem,
> > > maybe Tom can use my buffer method to make a buffer :-)
> > >
> >
> > The main reason we use vmap is so that from the kernel side we have a
> > nice contiguous address range to log to even though the the pages
> > aren't actually contiguous.
>
> That's what I meant, but you said it better :-)
>
> >
> > > See http://www.kihontech.com/logdev where my logdev debugging tool that
> > > allocates separate pages and uses an accounting system instead of the
> > > more efficient vmalloc to keep the data in the pages together. I'm
> > > currently working with Tom to get this to use relayfs as the back end.
> > > But here you can take a look at how the buffering works and it doesn't
> > > waste up vmalloc.
> >
> > It might be worthwhile to try out different alternatives and compare
> > them, but I'm pretty sure we won't be able to beat what's already in
> > relayfs. The question is I guess, how much slower would be
> > acceptable?
>
> I totally agree that the vmalloc way is faster, but I would also argue
> that the accounting to handle the separate pages would not even be
> noticeable with the time it takes to do the actual copying into the
> buffer. So if the accounting adds 3ns on top of 500ns to complete, I
> don't think people will mind.

OK, it sounds like something to experiment with - I can play around
with it, and later submit a patch to remove vmap if it works out.
Does that sound like a good idea?

Tom


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-07-12 18:50    [W:0.242 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site