Steven Rostedt writes: > On Tue, 2005-07-12 at 11:36 -0500, Tom Zanussi wrote: > > > > > > > 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? > > Sounds good to me, since different approaches to a problem are always > good, since it allows for comparing the plusses and minuses. Not sure > if you want to take a crack using my ring buffers, but although they are > quite confusing, they have been fully tested, since I haven't changed > the ring buffer for a few years (although logdev itself has gone through
I was thinking of something simpler, like just using the page array we already have in relayfs, but not vmap'ing it and instead writing to the current page, detecting when to split a record, moving on to the next page, etc. and seeing how it compares with the vmap version. 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/
