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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |