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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/