lkml.org 
[lkml]   [2005]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Merging relayfs?
From
Date
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.

I haven't looked too much into the workings of relayfs (I let you handle
that ;-) so I don't really know the impact it would have to use
something like logdev's buffering system.

-- Steve


-
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:34    [W:0.064 / U:0.588 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site