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

[Bart Van Assche <bvanassche@acm.org>]

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? I think that the
measurement data that I published shows that the fairness properties of
the current sbitmap implementation are good enough.

> This series proposes an entirely different fairness mechanism that
> doesn't require per-IO atomic accounting:
> 
>    First, the sbitmap API is augmented with a ranged allocator. This
>    allows a client to carve the depth into exclusive ranges for specific
>    users.
>    
>    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? 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?
Removing the tag fairness code increases IOPS so this patch series
probably has a performance impact.

Thanks,

Bart.