From: Ming Lei <ming.lei@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Li Ning <lining2020x@163.com>,
Chunguang Xu <brookxu@tencent.com>
Subject: Re: [PATCH V2 5/7] block: throttle split bio in case of iops limit
Date: Tue, 15 Feb 2022 09:10:18 +0800 [thread overview]
Message-ID: <Ygr9evnWSjcCjYkd@T590> (raw)
In-Reply-To: <Ygq6GanKSLlTixqe@slm.duckdns.org>
On Mon, Feb 14, 2022 at 10:22:49AM -1000, Tejun Heo wrote:
> Hello,
>
> On Wed, Feb 09, 2022 at 05:14:27PM +0800, Ming Lei wrote:
> > Chunguang Xu has already observed this issue and fixed it in commit
> > 4f1e9630afe6 ("blk-throtl: optimize IOPS throttle for large IO scenarios").
> > However, that patch only covers bio splitting in __blk_queue_split(), and
> > we have other kind of bio splitting, such as bio_split() &
> > submit_bio_noacct() and other ways.
>
> I see. So, we can go for adding split handling to all other places or try to
> find a common spot.
>
> > This patch tries to fix the issue in one generic way by always charging
> > the bio for iops limit in blk_throtl_bio(). This way is reasonable:
> > re-submission & fast-cloned bio is charged if it is submitted to same
> > disk/queue, and BIO_THROTTLED will be cleared if bio->bi_bdev is changed.
> >
> > This new approach can get much more smooth/stable iops limit compared with
> > commit 4f1e9630afe6 ("blk-throtl: optimize IOPS throttle for large IO
> > scenarios") since that commit can't throttle current split bios actually.
> >
> > Also this way won't cause new double bio iops charge in
> > blk_throtl_dispatch_work_fn() in which blk_throtl_bio() won't be called
> > any more.
>
> But yeah, this should work too. This is simpler but more fragile given the
> twisted history around BIO_THROTTLED. I think the root cause of the
> convolution is that it's hooked at the wrong spot - it's sitting on top of
> the queue trying to guess what actually happens to the bios it sent down.
> Ideally, we probably wanna move this to rq-qos hooks which sit on the actual
> issue-to-the-device path.
The big problem is that rq-qos is only hooked for request based queue,
and we need to support cgroup/throttle for bio base queue.
>
> For now, I don't have a strong preference. This looks fine to me too. Please
> feel free to add
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> for the blk-throtl patches.
Thanks!
--
Ming
next prev parent reply other threads:[~2022-02-15 1:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-09 9:14 [PATCH V2 0/7] block: improve iops limit throttle Ming Lei
2022-02-09 9:14 ` [PATCH V2 1/7] block: move submit_bio_checks() into submit_bio_noacct Ming Lei
2022-02-09 14:01 ` Christoph Hellwig
2022-02-09 9:14 ` [PATCH V2 2/7] block: move blk_crypto_bio_prep() out of blk-mq.c Ming Lei
2022-02-09 14:02 ` Christoph Hellwig
2022-02-09 9:14 ` [PATCH V2 3/7] block: don't declare submit_bio_checks in local header Ming Lei
2022-02-09 14:02 ` Christoph Hellwig
2022-02-09 9:14 ` [PATCH V2 4/7] block: don't check bio in blk_throtl_dispatch_work_fn Ming Lei
2022-02-09 14:03 ` Christoph Hellwig
2022-02-09 9:14 ` [PATCH V2 5/7] block: throttle split bio in case of iops limit Ming Lei
2022-02-14 20:22 ` Tejun Heo
2022-02-15 1:10 ` Ming Lei [this message]
2022-02-15 7:08 ` Christoph Hellwig
2022-02-15 8:02 ` Ming Lei
2022-02-15 8:17 ` Ning Li
2022-02-15 8:20 ` Ning Li
2022-02-09 9:14 ` [PATCH V2 6/7] block: don't try to throttle split bio if iops limit isn't set Ming Lei
2022-02-09 9:14 ` [PATCH V2 7/7] block: revert 4f1e9630afe6 ("blk-throtl: optimize IOPS throttle for large IO scenarios") Ming Lei
2022-02-13 8:34 ` [PATCH V2 0/7] block: improve iops limit throttle Ming Lei
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=Ygr9evnWSjcCjYkd@T590 \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=brookxu@tencent.com \
--cc=lining2020x@163.com \
--cc=linux-block@vger.kernel.org \
--cc=tj@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).