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.024 / U:0.772 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site