On Fri, Feb 14, 2025 at 2:25 PM Bernd Schubert
<bernd.schubert@xxxxxxxxxxx> wrote:
>
>
> On 2/14/25 22:26, Joanne Koong wrote:
> > On Fri, Feb 14, 2025 at 12:27 PM Bernd Schubert
> > <bernd.schubert@xxxxxxxxxxx> wrote:
> >>
> >> Hi Joanne,
> >>
> >> On 2/14/25 21:01, Joanne Koong wrote:
> >>> On Wed, Aug 21, 2024 at 8:04 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> >>>>
> >>>> On Wed, 21 Aug 2024 at 16:44, Bernd Schubert <bernd.schubert@xxxxxxxxxxx> wrote:
> >>>>
> >>>>> struct atomic_open
> >>>>> {
> >>>>> uint64_t atomic_open_flags;
> >>>>> struct fuse_open_out open_out;
> >>>>> uint8_t future_padding1[16];
> >>>>> struct fuse_entry_out entry_out;
> >>>>> uint8_t future_padding2[16];
> >>>>> }
> >>>>>
> >>>>>
> >>>>> What do you think?
> >>>>
> >>>> I'm wondering if something like the "compound procedure" in NFSv4
> >>>> would work for fuse as well?
> >>>
> >>> Are compound requests still something that's planned to be added to
> >>> fuse given that fuse now has support for sending requests over uring,
> >>> which diminishes the overhead of kernel/userspace context switches for
> >>> sending multiple requests vs 1 big compound request?
> >>>
> >>> The reason I ask is because the mitigation for the stale attributes
> >>> data corruption for servers backed by network filesystems we saw in
> >>> [1] is dependent on this patch / compound requests. If compound
> >>> requests are no longer useful / planned, then what are your thoughts
> >>> on [1] as an acceptable solution?
> >>
> >
> > Hi Bernd,
> >
> >> sorry, I have it in our ticket system, but I'm totally occupied with
> >> others issues for weeks *sigh*
> >>
> >
> > No worries!
> >
> >> Does io-uring really help if there is just on application doing IO to
> >> the current core/ring-queue?
> >>
> >> open - blocking fg request
> >> getattr - blocking fg request
> >>
> >
> > My understanding (and please correct me here if i'm wrong) is that the
> > main benefit of compound requests is that it bundles multiple requests
> > into 1 request to minimize kernel/userspace context switches. For fuse
>
> I think it would be good, to give fuse-server also the chance to handle
> the compound on its own. Example, sshfs would benefit from it as well
> (ok, the sftp protocol needs to get an extension, afaik), see here
>
> https://github.com/libfuse/libfuse/issues/945
>
> If sshfs would now do two requests, it would introduce double network
> latency - not your about you, but from my home to main lab hardware
> (US) that would already be quite noticeable.
> If sshfs/sftp would get a protocol extension and handle open+getattr
> in one request, there would be basically zero overhead.
>
> > io-uring [2], "motivation ... is... to increase fuse performance by:
> > Reducing kernel/userspace context switches. Part of that is given by
> > the ring ring - handling multiple requests on either side of
> > kernel/userspace without the need to switch per request".
> >
> > Am I missing something in my understanding of io-uring reducing
> > context switches?
>
> With fuse-io-uring we have reduced context switches, because
> result submit can immediately fetch the next request, vs previous
> read + write.
>
> Then we also avoid context switches if the ring is busy - it
What does it mean for the ring to be "busy"? As in it has multiple
requests queued on it?
> can stay on either side if there is still work to do.
Can you explain what "there is still work to do" here means?
>
> For open and then getattr and if the ring is idle, we still
> have the overhead of two independent operations.
>
> One issue I'm currently working is is reducing memory overhead,
> we actually might need a fuse-io-uring mode with less rings.
> In that mode chances to have a busy ring are higher. Although
> I'm still fighting against it, because it takes away core affinity
> and that was showing 3x performance gains with blocking / fg requests.
>
Awesome, excited to hear the updates on this when you have them. We
will encounter the same issue.
>
> >
> >
> >> If we could dispatch both as bg request and wait for the response it
> >> might work out, but in the current form not ideal.
> >>
> >> I can only try to find the time over the weekend to work on the
> >> compound reuqest, although need to send out the other patch and
> >> especially to test it (the one about possible list corruption).
> >
> > If you need an extra pair of hands, i'm happy to help out with this.
> > Internally, we'd like to get the proper fix in for the issue in [1],
> > but we have a hacky workaround for it right now (returning -ESTALE to
> > redo the lookup and update the file size), so we're not in a huge
> > rush.
>
>
> Could you ping me in latest two weeks again? Either I found some
> time for compound requests by then, or we need to go the easier
> way. As long as our DLM mode is not ready we also need this
> feature, just a lot of the more urgent issues before that.
>
Sounds good, thanks!
>
>
> Thanks,
> Bernd
