Re: [RFC PATCH 0/6] sbitmap enforced fairness for blk-mq

[Keith Busch <kbusch@kernel.org>]

On Mon, Jul 06, 2026 at 10:56:05AM -0700, Bart Van Assche wrote:
> On 7/6/26 10:34 AM, Keith Busch wrote:
> > There have been a few proposals to remove the blk-mq tag fairness
> > algorithm:
> > 
> >   https://lore.kernel.org/linux-block/20240529213921.3166462-1-bvanassche@acm.org/
> >   https://lore.kernel.org/linux-block/20260609121806.2121755-1-sumit.saxena@broadcom.com/
> 
> There have been more proposals to remove the fairness code from other
> kernel contributors. I proposed to remove the tag fairness code because
> prior attempts to solve UFS performance issues were not good enough for
> the upstream kernel.
> 
> > Both abandon blk-mq's attempt to enforce tag allocation limits on the
> > per-queue/per-hctx users that share tag space. This can harm resource
> > allocation for lesser devices sharing the space, potentially starving,
> > them from fair progress by a highly utilized device.
> 
> Has this starving phenomenon ever been observed? 

If you're asking if a production workload sees the phenomenon, no
because they run the code that has enforced fairness.

> I think that the
> measurement data that I published shows that the fairness properties of
> the current sbitmap implementation are good enough.

I can trivially wire up a test where one queue allocates 100% of the
tags for long running commands, and all the other queues that want to
start a short running command can't proceed.

> >    Second, you can optionally declare a percentage of that pool to be
> >    fair game for anyone to allocate from. This provides a way to
> >    guarantee minimum tag space for each client while allowing a user to
> >    over-allocate its fair budget on demand into the shared zone.
> 
> What software layer is expected to set these percentages? 

It's a tagset parameter that the LLD can set to whatever it needs.

> My patch
> series intentionally removes the fairness mechanism because that's
> exactly what the legacy code path in the UFS driver needs. The UFS
> WLUN and data logical units share a single tag set. Any activity on
> the WLUN increases the number of active queues and hence reduces the
> number of tags available for any data logical units.
> 
> Additionally, what is the performance impact of this patch series?

It removes the per-io atomics, so impact is it goes faster if that was
your bottle-neck.

> Removing the tag fairness code increases IOPS so this patch series
> probably has a performance impact.

You can declare the entire tagset is shared if you want. That should get
you what you were going for, but we still have an option to spatially
constrain others that want fairness with this series.