Tom Zanussi writes: > 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. >
Just a clarification - I didn't mean to ignore your ring buffers - it would be good to try both, I think... 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/
