Messages in this thread | | | Date | Thu, 20 Apr 2006 21:19:55 +0200 | From | Jens Axboe <> | Subject | Re: Linux 2.6.17-rc2 |
| |
On Thu, Apr 20 2006, Linus Torvalds wrote: > > > On Thu, 20 Apr 2006, Jens Axboe wrote: > > > > > - an ioctl/fcntl to set the maximum size of the buffer. Right now it's > > > hardcoded to 16 "buffer entries" (which in turn are normally limited to > > > one page each, although there's nothing that _requires_ that a buffer > > > entry always be a page). > > > > This is on a TODO, but not very high up since I've yet to see a case > > where the current 16 page limitation is an issue. I'm sure something > > will come up eventually, but until then I'd rather not bother. > > The real reason for limiting the number of buffer entries is not to make > the number _larger_ (although that can be a performance optimization), but > to make it _smaller_ or at least knowing/limiting how big it is. > > It doesn't matter with the current interfaces which are mostly agnostic as > to how big the buffer is, but it _does_ matter with vmsplice(). > > Why? > > Simple: for a vmsplice() user, it's very important to know when they can > start re-using the buffer(s) that they used vmsplice() on previously. And > while the user could just ask the kernel how many bytes are left in the > pipe buffer, that's pretty inefficient for many normal streaming cases. > > The _efficient_ way is to make the user-space buffer that you use for > splicing information to another entity a circular buffer that is at least > as large as any of the splice pipes involved in the transfer (depending on > use. In many cases, you will probably want to make the user-space buffer > _twice_ as big as the kernel buffer, which makes the tracking even easier: > while half of the buffer is busy, you can write to the half that is > guaranteed to not be in the kernel buffer, so you effectively do "double > buffering") > > So if you do that, then you can continue to write to the buffer without > ever worrying about re-use, because you know that by the time you wrap > around, the kernel buffer will have been flushed out, or the vmsplice() > would have blocked, waiting for the receiver. So now you no longer need to > worry about "how much has flushed" - you only need to worry about doing > the vmsplice() call at least twice per buffer traversal (assuming the > "user buffer is double the size of the kernel buffer" approach). > > So you could do a very efficient "stdio-like" implementation for logging, > for example, since this allows you to re-use the same pages over and over > for splicing, without ever having any copying overhead, and without ever > having to play VM-related games (ie you don't need to do unmaps or > mprotects or anything expensive like that in order to get a new page or > something). > > But in order to do that, you really do need to know (and preferably set) > the size of the splice buffer. Otherwise, if the in-kernel splice buffer > is larger than the circular buffer you use in user space, the kernel will > add the same page _twice_ to the buffer, and you'll overwrite the data > that you already spliced.
Good point, as you can tell I had other uses in mind for this. I'd prefer using fcntl for this instead of an ioctl - how about a set of matching F_SETPIPESZ/F_GETPIPESZ or something in that order? Right now we can just -EINVAL stub the pipe size setting, but really implement the pipe size getting.
Other suggestions?
The vmsplice addition itself is pretty slim:
splice.c | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 132 insertions(+), 31 deletions(-)
> (Now, you still need to be very careful with vmsplice() in general, since > it leaves the data page writable in the source VM and thus allows for all > kinds of confusion, but the theory here is "give them rope". Rope enough > to do clever things always ends up being rope enough to hang yourself too. > Tough.).
Oh definitely :-)
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |