Re: Merging relayfs?

[Tom Zanussi <zanussi@us.ibm.com>]

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/