Re: [PATCH v3 3/4] block: drop shared-tag fairness throttling

[Christoph Hellwig]

Just dropping the fairness was rejected before and there is no
explanation here on why any of that has changed.

On Tue, Jun 09, 2026 at 05:48:02PM +0530, Sumit Saxena wrote:
> From: Bart Van Assche <bvana...@acm.org>
>
> Original patch [1] by Bart Van Assche; this version is rebased onto the
> current tree. In testing it improves IOPS by roughly 16-18% by removing
> the fair-sharing throttle on shared tag queues.
>
> This patch removes the following code and structure members:
> - The function hctx_may_queue().
> - blk_mq_hw_ctx.nr_active and request_queue.nr_active_requests_shared_tags
> and also all the code that modifies these two member variables.

.. and besides that, this commit message is still entirely useless
as it doesn't explain any of the thoughts of why this change is safe
and desirable. While the mechanics above are totally obvious from
the code change itself.

[Hannes Reinecke]

On 6/9/26 14:18, Sumit Saxena wrote:
> From: Bart Van Assche <bvana...@acm.org>
>
> Original patch [1] by Bart Van Assche; this version is rebased onto the
> current tree. In testing it improves IOPS by roughly 16-18% by removing
> the fair-sharing throttle on shared tag queues.
>
> This patch removes the following code and structure members:
> - The function hctx_may_queue().
> - blk_mq_hw_ctx.nr_active and request_queue.nr_active_requests_shared_tags
> and also all the code that modifies these two member variables.
>

> [1]: https://lore.kernel.org/linux-block/20240529213921.31...@acm.org/
>
> Signed-off-by: Bart Van Assche <bvana...@acm.org>
> Signed-off-by: Sumit Saxena <sumit....@broadcom.com>
> ---
> block/blk-core.c | 2 -
> block/blk-mq-debugfs.c | 22 ++++++++-
> block/blk-mq-tag.c | 4 --
> block/blk-mq.c | 17 +------
> block/blk-mq.h | 100 -----------------------------------------
> include/linux/blk-mq.h | 6 ---
> include/linux/blkdev.h | 2 -
> 7 files changed, 22 insertions(+), 131 deletions(-)
>
What tests did you perform?
I'm pretty sure you see an improvement when having just a few drives,
but what about having a lot of them (ie tens of drives)?
The whole point of this was to increase fairness between drives, so
of course removing it will make an individual drive going faster ...

Maybe it's an idea to move the fairness algorithm into an I/O scheduler;
that way we can keep the original behaviour yet get the performance
increase if people want it.

Cheers,

Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
ha...@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

[Bart Van Assche]

On 6/9/26 11:14 PM, Christoph Hellwig wrote:
> Just dropping the fairness was rejected before and there is no
> explanation here on why any of that has changed.

Hmm ... has anyone ever rejected this patch? Jens' latest feedback
(May 2024) is available here:
https://lore.kernel.org/linux-block/7a69eba2-42e4-4c67...@kernel.dk/

Thanks,

Bart.

[Bart Van Assche]

On 6/9/26 11:18 PM, Hannes Reinecke wrote:
> The whole point of this was to increase fairness between drives, so
> of course removing it will make an individual drive going faster ...

Data that shows that fairness is preserved even with this patch applied
is available here:
https://lore.kernel.org/linux-block/20240529213921.31...@acm.org/

Thanks,

Bart.