On Tue, 2005-07-12 at 16:38 -0500, Tom Zanussi wrote: > Tom Zanussi writes: > > > > > > 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...
Oh, by all means, simple is usually better. I didn't take any offense to not using it. My ring buffers are quite confusing, and took quite of bit debugging to finally get them straight. If you get something that works then it should be good to go. My ring buffers were meant to be always used as a ring buffer that would only save the latest data and not stop when full. So, each page had to have it's own start and stop since the beginning of the buffer could actually be anywhere on any page. That's because, once the ring buffer filled up, the start of the buffer would move as you added more data. A simple approach should be best, but if you start doing the individual page accounting, and find that it's getting complex to handle all cases, then it's good to know that my ring buffers are always out there :-) I will also admit that my ring buffers lost one byte per page. Because I wanted to save on space with the accounting, and only had a start and end pointer per page. So when start and end were equal, the buffer was considered empty and when end was one less than start, it was considered full. But since end always pointed to an empty spot, it would still be empty when the buffer was full, thus wasting one byte per page. But to solve this, I would either have to add another variable in the buffer page descriptor (adding at least one byte, but probably 4 bytes) which would just be more waste, or I would have to make a complex system even more complex (ie. adding a flag on the end pointer at the MSB to differentiate between end being empty or filled). -- Steve - 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/
