Re: Re: Re: [PATCH v5 1/3] fuse: add compound command to combine multiple requests

[Joanne Koong]

On Sat, Feb 14, 2026 at 9:51 AM Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
>
> On Fri, Feb 13, 2026 at 05:35:30PM -0800, Joanne Koong wrote:
> > On Thu, Feb 12, 2026 at 3:44 AM Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
> > > I have a feeling we have different use cases in mind and misunderstand each other.
> > >
> > > As I see it:
> > > From the discussion a while ago that actually started the whole thing I understand
> > > that we have combinations of requests that we want to bunch together for a
> > > specific semantic effect. (see OPEN+GETATTR that started it all)
> > >
> > > If that is true, then bunching together more commands to create 'compounds' that
> > > semantically linked should not be a problem and we don't need any algorithm for
> > > recosntructing the args. We know the semantics on both ends and craft the compounds
> > > according to what is to be accomplished (the fuse server just provides the 'how')
> > >
> > > From the newer discussion I have a feeling that there is the idea floating around
> > > that we should bunch together arbitrary requests to have some performance advantage.
> > > This was not my initial intention.
> > > We could do that however if we can fill the args and the requests are not
> > > interdependent.
> >
> > I have a series of (very unpolished) patches from last year that does
> > basically this. When libfuse does a read on /dev/fuse, the kernel
> > crams in as many requests off the fiq list as it can fit into the
> > buffer. On the libfuse side, when it iterates through that buffer it
> > offloads each request to a worker thread to process/execute that
> > request. It worked the same way on the dev uring side. I put those
> > changes aside to work on the zero copy stuff, but if there's interest
> > I can go back to those patches and clean them up and put them through
> > some testing. I don't think the work overlaps with your compound
> > requests stuff though. The compound requests would be a request inside
> > the larger batch.
>
> I would like to have your patch for the processing of multiple requests
> and the compound for handling semantically related requests.
>

the kernel-side changes for the /dev/fuse request batching are pretty
self-contained [1] but the libfuse changes are very ugly. The
benchmarks didn't look promising. I think it only really helps if the
server has metadata-heavy bursty behavior that saturates all the
libfuse threads, but I don't think that's typical. I dont think it's
worth pursuing further.

Thanks,
Joanne

[1]  https://github.com/joannekoong/linux/commit/308ebbde134ac98d3b3d3e2f3abc2c52ef444759