Re: [PATCH v4 7/8] fuse: Add retry attempts for numa local queues for load distribution

[Bernd Schubert <bschubert@ddn.com>]

On 4/29/26 17:03, Joanne Koong wrote:
> On Mon, Apr 13, 2026 at 10:41 AM Bernd Schubert via B4 Relay
> <devnull+bernd.bsbernd.com@kernel.org> wrote:
>>
>> From: Bernd Schubert <bschubert@ddn.com>
>>
>> This is to further improve performance.
>>
>> fio --directory=/tmp/dest --name=iops.\$jobnum --rw=randread \
>> --bs=4k --size=1G --numjobs=1 --iodepth=4 --time_based\
>> --runtime=30s --group_reporting --ioengine=io_uring\
>> --direct=1
>>
>> unpatched
>>    READ: bw=650MiB/s (682MB/s)
>> patched:
>>    READ: bw=995MiB/s (1043MB/s)
>>
>> with --iodepth=8
>>
>> unpatched
>>    READ: bw=641MiB/s (672MB/s)
>> patched
>>    READ: bw=966MiB/s (1012MB/s)
>>
>> Reason is that with --iodepth=x (x > 1) fio submits multiple async
>> requests and a single queue might become CPU limited. I.e. spreading
>> the load helps.
>> ---
>>  fs/fuse/dev_uring.c | 30 ++++++++++++++++++++++++++++--
>>  1 file changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/fuse/dev_uring.c b/fs/fuse/dev_uring.c
>> index ed061e239b8ed70ff36deb51dd6957fe1704ec87..e06d45b161d5000e24431314b2222b66bdea58aa 100644
>> --- a/fs/fuse/dev_uring.c
>> +++ b/fs/fuse/dev_uring.c
>> @@ -19,6 +19,7 @@ MODULE_PARM_DESC(enable_uring,
>>
>>  #define FUSE_URING_IOV_SEGS 2 /* header and payload */
>>
>> +#define FUSE_URING_Q_THRESHOLD 2
>>
>>  bool fuse_uring_enabled(void)
>>  {
>> @@ -1310,9 +1311,10 @@ static struct fuse_ring_queue *fuse_uring_select_queue(struct fuse_ring *ring,
>>                                                        bool background)
>>  {
>>         unsigned int qid;
>> -       int node;
>> +       int node, retries = 0;
>>         unsigned int nr_queues;
>>         unsigned int cpu = task_cpu(current);
>> +       struct fuse_ring_queue *queue, *primary_queue = NULL;
>>
>>         /*
>>          *  Background requests result in better performance on a different
>> @@ -1321,6 +1323,7 @@ static struct fuse_ring_queue *fuse_uring_select_queue(struct fuse_ring *ring,
>>         if (background)
>>                 cpu++;
>>
>> +retry:
>>         cpu = cpu % ring->max_nr_queues;
>>
>>         /* numa local registered queue bitmap */
>> @@ -1336,12 +1339,35 @@ static struct fuse_ring_queue *fuse_uring_select_queue(struct fuse_ring *ring,
>>                 qid = ring->numa_q_map[node].cpu_to_qid[cpu];
>>                 if (WARN_ON_ONCE(qid >= ring->max_nr_queues))
>>                         return NULL;
>> -               return READ_ONCE(ring->queues[qid]);
>> +               queue = READ_ONCE(ring->queues[qid]);
>> +
>> +               /* Might happen on teardown */
>> +               if (unlikely(!queue))
>> +                       return NULL;
>> +
>> +               if (queue->nr_reqs < FUSE_URING_Q_THRESHOLD)
> 
> Should this use READ_ONCE(queue->nr_reqs) since nr_reqs may be
> concurrently modified under the queue lock by other CPUs while we're
> reading it locklessly here?

Definitely makes sense, hopefully it will not disturb a hot path.

> 
>> +                       return queue;
>> +
>> +               /* Retries help for load balancing */
>> +               if (retries < FUSE_URING_Q_THRESHOLD) {
>> +                       if (!retries)
>> +                               primary_queue = queue;
>> +
>> +                       /* Increase cpu, assuming it will map to a differet qid*/
>> +                       cpu++;
> 
> Here too I think cpu++ can break numa locality. In the reduced-queue
> setup, I think cpu++ may have a solid chance at mapping back to the
> same qid.

It needs the same quirk - read node on function entry.

> 
> If we use the ring->numa_q_map[node].registered_q_mask and the
> cpumask_next_wrap() helper to find the next qid in the numa node, i
> think that will guarantee numa locality, a different qid, avoids
> having to redo the whole cpu_to_node() + nr_queues lookup on each
> retry, and will detect automatically when all queues on the node have
> been tried.
> 
> If you dont have the bandwidth to consider this change for v5, I can
> send a followup patch for it.

I should have the time on Friday, and hopefully I find a bit time to
look into the way how blk-mqueue does it before next week.


Thanks,
Bernd