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

[Sumit Saxena <sumit.saxena@xxxxxxxxxxxx>]

On Wed, Jun 10, 2026 at 11:44 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
>
> Just dropping the fairness was rejected before and there is no
> explanation here on why any of that has changed.

I missed the fact that this patch had been previously rejected.

The motivation for this change stems from performance issue we
encountered due to false sharing of the 'nr_active_requests_shared_tags' counter
on certain CPU architectures. I initially submitted a patch to move that counter to
its own cache line to avoid conflicts with 'nr_requests' and other hot fields
(see: https://patchwork.kernel.org/project/linux-scsi/patch/20260402074637.92417-3-sumit.saxena@xxxxxxxxxxxx/).

During the review, Bart shared his work, which eliminates the
counter entirely by removing the fairness throttling. My testing confirmed that
this approach resolved the performance issues and improved IOPS.
This patch is part of a larger set, and I have reported the cumulative performance
improvements in the cover letter.

Thanks,
Sumit

>
> On Tue, Jun 09, 2026 at 05:48:02PM +0530, Sumit Saxena wrote:
> > From: Bart Van Assche <bvanassche@xxxxxxx>
> >
> > 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.
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature