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

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 <[email protected]>
>> ---
>> 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/[email protected]
>>
>> ---
>> 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...


Thanks,
Bernd