Re: [RFC PATCH 0/1] fuse: per-queue background request accounting for io-uring

[Bernd Schubert <bernd@bsbernd.com>]

Hi Alexsander,

On 10/16/26 14:48, Aleksander Trofimowicz wrote:
> fuse: per-queue background request accounting for io-uring
> 
> This RFC proposes an opt-in path to replace the connection-wide
> background request accounting in fuse io-uring with per-queue
> budgeting.
> 
> AFAIR the concept has already floated on the list, but nothing has
> come to fruition. Nonetheless the problem is obvious: the existing
> implementation relies on a single connection-wide spinlock
> (fch->bg_lock) that is taken twice while servicing background
> requests. That severely hampers the scalability of fuse io-uring for
> certain types of workload (e.g. direct async I/O). Suffice it to say,
> with this patch applied I can easily cross the 1M 4k random read IOPS
> barrier, while the baseline gives a mere 600k IOPS (caeteris paribus).
> 
> I envision this enhancement being negotiated with a daemon, but for
> your convenience the feature can currently be activated
> unconditionally via the uring_max_bg_per_queue_force parameter. Mind
> that the value of uring_max_bg_per_queue must also be increased to
> obtain any meaningful results.
> 
> I am looking forward to your feedback. Thanks in advance.

I wasn't doing this yet, because I see it dependent on the reduced
queue feature, which also allows to distribute requests to another
queue, when a queue already got too many requests. I.e. if a queue
is over its own bg-limit, it should check if other queues are
available.

I plan to send out next version of reduced queues over the weekend.


Thanks,
Bernd