From: Ming Lei <ming.lei@redhat.com>
To: "yukuai (C)" <yukuai3@huawei.com>
Cc: Tejun Heo <tj@kernel.org>,
Zhang Wensheng <zhangwensheng5@huawei.com>,
axboe@kernel.dk, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org
Subject: Re: [PATCH -next] block: fix io hung of setting throttle limit frequently
Date: Tue, 17 May 2022 15:49:58 +0800 [thread overview]
Message-ID: <YoNTpswO2+tEWbWo@T590> (raw)
In-Reply-To: <ca251645-8d52-7a93-6ac2-579d97922a9e@huawei.com>
On Tue, May 17, 2022 at 11:12:28AM +0800, yukuai (C) wrote:
> 在 2022/05/17 3:29, Tejun Heo 写道:
> > On Mon, May 16, 2022 at 09:44:29AM +0800, Zhang Wensheng wrote:
> > > diff --git a/block/blk-throttle.c b/block/blk-throttle.c
> > > index 469c483719be..8acb205dfa85 100644
> > > --- a/block/blk-throttle.c
> > > +++ b/block/blk-throttle.c
> > > @@ -1321,12 +1321,14 @@ static void tg_conf_updated(struct throtl_grp *tg, bool global)
> > > * that a group's limit are dropped suddenly and we don't want to
> > > * account recently dispatched IO with new low rate.
> > > */
> > > - throtl_start_new_slice(tg, READ);
> > > - throtl_start_new_slice(tg, WRITE);
> > > + if (!timer_pending(&sq->parent_sq->pending_timer)) {
> > > + throtl_start_new_slice(tg, READ);
> > > + throtl_start_new_slice(tg, WRITE);
> > > - if (tg->flags & THROTL_TG_PENDING) {
> > > - tg_update_disptime(tg);
> > > - throtl_schedule_next_dispatch(sq->parent_sq, true);
> > > + if (tg->flags & THROTL_TG_PENDING) {
> > > + tg_update_disptime(tg);
> > > + throtl_schedule_next_dispatch(sq->parent_sq, true);
> > > + }
> >
> > Yeah, but this ends up breaking the reason why it's starting the new slices
> > in the first place explained in the commit above, right? I'm not sure what
> > the right solution is but this likely isn't it.
> >
> Hi, Tejun
>
> Ming added a condition in tg_with_in_bps_limit():
> - if (bps_limit == U64_MAX) {
> + /* no need to throttle if this bio's bytes have been accounted */
> + if (bps_limit == U64_MAX || bio_flagged(bio, BIO_THROTTLED)) {
>
> Which will let the first throttled bio to be issued immediately once
> the config if updated.
>
> Do you think this behaviour is OK? If so, we can do the same for
> tg_with_in_iops_limit.
IMO, you can't do that for iops limit. If BIO_THROTTLED is set for one
bio, all its bytes have been accounted, so no need to throttle this bio
in case of bps limit. iops limit is another story, since io account is
done in request IO which is based on split bio, so the bio(split bio)
still need to be check & throttle in case of iops limit.
Thanks,
Ming
prev parent reply other threads:[~2022-05-17 7:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 1:44 [PATCH -next] block: fix io hung of setting throttle limit frequently Zhang Wensheng
2022-05-16 19:29 ` Tejun Heo
2022-05-17 3:12 ` yukuai (C)
2022-05-17 4:18 ` Tejun Heo
2022-05-17 6:16 ` yukuai (C)
2022-05-17 7:49 ` Ming Lei [this message]
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=YoNTpswO2+tEWbWo@T590 \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=yukuai3@huawei.com \
--cc=zhangwensheng5@huawei.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