From: Bart Van Assche <bvanassche@acm.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org,
"Martin K . Petersen" <martin.petersen@oracle.com>,
Ming Lei <ming.lei@redhat.com>, Keith Busch <kbusch@kernel.org>,
Damien Le Moal <damien.lemoal@opensource.wdc.com>,
Yu Kuai <yukuai1@huaweicloud.com>, Ed Tsai <ed.tsai@mediatek.com>
Subject: Re: [PATCH] block: Improve shared tag set performance
Date: Fri, 20 Oct 2023 09:17:11 -0700 [thread overview]
Message-ID: <0d2dce2a-8e01-45d6-b61b-f76493d55863@acm.org> (raw)
In-Reply-To: <20231020044159.GB11984@lst.de>
On 10/19/23 21:41, Christoph Hellwig wrote:
> On Wed, Oct 18, 2023 at 11:00:56AM -0700, Bart Van Assche wrote:
>> Note: it has been attempted to rework this algorithm. See also "[PATCH
>> RFC 0/7] blk-mq: improve tag fair sharing"
>> (https://lore.kernel.org/linux-block/20230618160738.54385-1-yukuai1@huaweicloud.com/).
>> Given the complexity of that patch series, I do not expect that patch
>> series to be merged.
>
> Work is hard, so let's skip it? That's not really the most convincing
> argument. Hey, I'm the biggest advocate for code improvement by code
> removal, but you better have a really good argument why it doesn't hurt
> anyone.
Hi Christoph,
No, it's not because it's hard to improve the tag fairness algorithm
that I'm proposing to skip this work. It's because I'm convinced that
an improved fairness algorithm will have a negative performance impact
that is larger than that of the current algorithm.
Do you agree that the legacy block layer never had any such fairness
algorithm and also that nobody ever complained about fairness issues
for the legacy block layer? I think that's a strong argument in favor of
removing the fairness algorithm.
Thanks,
Bart.
next prev parent reply other threads:[~2023-10-20 16:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 18:00 [PATCH] block: Improve shared tag set performance Bart Van Assche
2023-10-20 4:41 ` Christoph Hellwig
2023-10-20 16:17 ` Bart Van Assche [this message]
2023-10-20 16:25 ` Keith Busch
2023-10-20 16:45 ` Bart Van Assche
2023-10-20 17:09 ` Keith Busch
2023-10-20 17:54 ` Bart Van Assche
2023-10-21 1:31 ` Ming Lei
2023-10-21 16:13 ` Bart Van Assche
2023-10-23 3:44 ` Ming Lei
2023-10-20 19:11 ` Bart Van Assche
2023-10-21 7:32 ` Yu Kuai
2023-10-21 16:21 ` Bart Van Assche
2023-10-23 1:11 ` Yu Kuai
-- strict thread matches above, loose matches on Subject: below --
2023-01-02 17:39 Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0d2dce2a-8e01-45d6-b61b-f76493d55863@acm.org \
--to=bvanassche@acm.org \
--cc=axboe@kernel.dk \
--cc=damien.lemoal@opensource.wdc.com \
--cc=ed.tsai@mediatek.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
--cc=yukuai1@huaweicloud.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox