Re: [PATCH v5 0/7] fuse: {io-uring} Allow to reduce the number of queues and request distribution

[David Wei <dw@davidwei.uk>]

On 2026-08-19 09:12, David Wei wrote:
> On 2026-08-17 14:39, Bernd Schubert wrote:
>>
>>
>> On 8/14/26 22:55, David Wei wrote:
>>> On 2026-05-28 15:55, Bernd Schubert via B4 Relay wrote:
>>>> This adds bitmaps that track which queues are registered and which queues
>>>> do not have queued requests.
>>>> These bitmaps are then used to map from request core to queue
>>>> and also allow load distribution. NUMA affinity is handled and
>>>> fuse client/server protocol does not need changes, all is handled
>>>> in fuse client internally.
>>>>
>>>> Signed-off-by: Bernd Schubert <bschubert@ddn.com>
>>>> ---
>>>> Changes in v5
>>>> - Rebased to miklos-for-next (Linux 7.2 base).
>>>> - Folded "Fetch a queued fuse request on command registration" into
>>>>     "Allow reduced number of ring queues", inlining fuse_uring_do_register()
>>>>     into fuse_uring_register().
>>>>     - Fixed retry logic in "Add retry attempts for numa local queues":
>>>>       replaced cpu++ with cpumask_next_wrap(qid, mask) so each retry
>>>>       advances to a genuinely different registered queue (Joanne)-
>>>>     - Simplified "Prefer the current core over mapping" (Joanne).
>>>>     - Folded READ_ONCE() annotation for ring->ready into "Allow reduced
>>>>       number of ring queues" to match WRITE_ONCE() on the writer side and
>>>>       suppress a KCSAN data-race warning.
>>>>
>>>> Changes in v4:
>>>> - Fix leak of ring->numa_q_map
>>>> - Fix q-imbalance due to an issue in static cpu->qid mapping
>>>> - Performance tunings, like preferring the current cpu
>>>> - Removal of distribution among queues, Joanne had concerns about it.
>>>>     As it is an optimization, it can be added later again. At least
>>>>     most of it was removed, some light distribution is still left in.
>>>> - At the end of the series, add fuse debugfs entries. This could
>>>>     be factored out.
>>>> - Link to v3: https://lore.kernel.org/r/20251013-reduced-nr-ring-queues_3-v3-0-6d87c8aa31ae@ddn.com
>>>>
>>>> ---
>>>> Bernd Schubert (7):
>>>>         fuse: {io-uring} Add queue length counters
>>>>         fuse: {io-uring} Rename ring->nr_queues to max_nr_queues
>>>>         fuse: {io-uring} Use bitmaps to track registered queues
>>>>         fuse: {io-uring} Allow reduced number of ring queues
>>>>         fuse: {io-uring} Queue background requests on a different core
>>>>         fuse: {io-uring} Add retry attempts for numa local queues for load distribution
>>>>         fuse: {io-uring} Prefer the current core over mapping
>>>>
>>>>    fs/fuse/dev_uring.c       | 313 ++++++++++++++++++++++++++++++++++------------
>>>>    fs/fuse/dev_uring_i.h     |  25 +++-
>>>>    fs/fuse/inode.c           |   2 +-
>>>>    include/uapi/linux/fuse.h |  10 +-
>>>>    4 files changed, 269 insertions(+), 81 deletions(-)
>>>> ---
>>>> base-commit: 2dcf16d41cc04472a4f9bc6e99d0ab26cfb1afb1
>>>> change-id: 20250722-reduced-nr-ring-queues_3-6acb79dad978
>>>>
>>>> Best regards,
>>
>> Hi David,
>>
>>>
>>> Hi Bernd,
>>>
>>> What is the current status of this patchset? Do you intend to keep it as
>>> is, or as Joanne mentioned combine it with queue add/remove?
>>
>> I think we should combine it with queue registration from Joannes series
>> and that got merged today. And with that should aim for the next merge
>> window. I also want to add in the RCU lock for mapping updates.
>>
>> Next step is that I need a merge request from Joanne for libfuse, so
>> that I can test with FUSE_IO_URING_CMD_ADD_QUEUE. Or at least I need the
>> branch. Well, I could add this in myself, but that would a) lead to
>> merge conflicts and b) cause even more work.
>>
>>>
>>> We're running FUSE io_uring on fairly large hosts with >150 physical
>>> cores. FUSE io_uring ends up creating 300+ io_uring instances, which
>>> wastes memory and bumps against rlimit memlock.
>>
>> I fully understand, however, I also cannot focus on one task only.
>> Besides having a totally different day job (right now fixing ublk_drv
>> tear-down issues), there is also libfuse (just check recent commit
>> history... I hadn't planned to rewrite tests, but I didn't get pytest to
>> hand out information what is failing. That all takes quite a bit of my
>> previous time). I'm fully open for co-maintainers...
> 
> Of course, I understand you have other things you're working on. I
> didn't want to step on your toes and work on something you've already
> made progress on. At the same time, it sounds like you're spread thin,
> so while I'm not certain on co-maintainership, perhaps we can talk about
> how to shard this work better?

Hi Bernd, following up on this. Can we work on queue add/remove which we
need to fix our problems with FUSE io_uring in parallel? You seem to be
spread very thin across different areas. We don't have the bandwidth to
co-maintain FUSE/libfuse, but we can work on the patches. What do you
think?

> 
>>
>>
>> Thanks,
>> Bernd