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

[Horst Birthelmer <horst@birthelmer.de>]

On Thu, Mar 05, 2026 at 04:52:01PM -0800, Joanne Koong wrote:
> On Sat, Feb 14, 2026 at 9:51 AM Horst Birthelmer <horst@birthelmer.de> 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@birthelmer.de> 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 for the patch. I agree completely. However I wrote that in the context
where I thought that people wanted to achieve something different with compound
requests, like processing parts of a queue depending on some or no criteria.
That's why I stressed the semantic relation of the requests in a compound.

I'm almost willing to bet that in the future we will see someone get
the idea of LOOKUP+OPEN+READ+CLOSE, which would practically
create exactly those bursts when not done as a compound.
Just as a side note ...

> 
> Thanks,
> Joanne
> 
> [1]  https://github.com/joannekoong/linux/commit/308ebbde134ac98d3b3d3e2f3abc2c52ef444759