On Tue, Mar 25, 2025 at 05:06:55PM +0100, Hanna Czenczek wrote: > We probably want to support larger write sizes than just 4k; 64k seems > nice. However, we cannot read partial requests from the FUSE FD, we > always have to read requests in full; so our read buffer must be large > enough to accommodate potential 64k writes if we want to support that. > > Always allocating FuseRequest objects with 64k buffers in them seems > wasteful, though. But we can get around the issue by splitting the > buffer into two and using readv(): One part will hold all normal (up to > 4k) write requests and all other requests, and a second part (the > "spill-over buffer") will be used only for larger write requests. Each > FuseQueue has its own spill-over buffer, and only if we find it used > when reading a request will we move its ownership into the FuseRequest > object and allocate a new spill-over buffer for the queue. > > This way, we get to support "large" write sizes without having to > allocate big buffers when they aren't used. > > Also, this even reduces the size of the FuseRequest objects because the > read buffer has to have at least FUSE_MIN_READ_BUFFER (8192) bytes; but > the requests we support are not quite so large (except for >4k writes), > so until now, we basically had to have useless padding in there. > > With the spill-over buffer added, the FUSE_MIN_READ_BUFFER requirement > is easily met and we can decrease the size of the buffer portion that is > right inside of FuseRequest. > > As for benchmarks, the benefit of this patch can be shown easily by > writing a 4G image (with qemu-img convert) to a FUSE export: > - Before this patch: Takes 25.6 s (14.4 s with -t none) > - After this patch: Takes 4.5 s (5.5 s with -t none) > > Signed-off-by: Hanna Czenczek <hre...@redhat.com> > --- > block/export/fuse.c | 137 ++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 118 insertions(+), 19 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
signature.asc
Description: PGP signature
