From: Ming Lei <ming.lei@redhat.com>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: tj@kernel.org, josef@toxicpanda.com, axboe@kernel.dk,
cgroups@vger.kernel.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, yi.zhang@huawei.com,
yangerkun@huawei.com, "yukuai (C)" <yukuai3@huawei.com>
Subject: Re: [PATCH 2/2] blk-throttle: fix off-by-one jiffies wait_time
Date: Tue, 25 Feb 2025 10:28:13 +0800 [thread overview]
Message-ID: <Z70qvZEBdq6L3-Yb@fedora> (raw)
In-Reply-To: <8473fca2-16ab-b2a6-ede7-d1449aa7d463@huaweicloud.com>
On Tue, Feb 25, 2025 at 10:07:06AM +0800, Yu Kuai wrote:
> Hi,
>
> 在 2025/02/25 9:24, Ming Lei 写道:
> > > - if (!time_elapsed)
> > > + /* don't trim slice until at least 2 slice is used */
> > > + if (time_elapsed < tg->td->throtl_slice * 2)
> > > return;
> >
> > If you just want to fix throtl/001, the above patch might
> > work(sometimes, it might not, and timer may expire by 2 jiffies), but it
> > is easy to fail other tests, such as, reduce the bps limit a bit, and
> > increase BS a bit to make the IO cross exactly two slices.
>
> That's fine, the key point is the following code, above code is
> just to make sure there is still at least one slice to trim after
> removing the last slice.
>
> + /* dispite the last slice, trim previous slice */
> + time_elapsed -= tg->td->throtl_slice;
>
> In this case, if one BIO cross 1+ slices, the rate is the same as
> expected in the previous slices, we can trim them without any negative
> impact.
Can you explain in details why it signals that the rate is expected now?
If rate isn't expected, it will cause trouble to trim, even just the
previous part.
Thanks,
Ming
next prev parent reply other threads:[~2025-02-25 2:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-22 9:28 [PATCH 0/2] blk-throttle: fix off-by-one jiffies wait_time Yu Kuai
2025-02-22 9:28 ` [PATCH 1/2] blk-throttle: cleanup throtl_extend_slice() Yu Kuai
2025-02-25 20:30 ` Tejun Heo
2025-02-22 9:28 ` [PATCH 2/2] blk-throttle: fix off-by-one jiffies wait_time Yu Kuai
2025-02-22 12:16 ` Ming Lei
2025-02-24 2:39 ` Yu Kuai
2025-02-24 3:28 ` Ming Lei
2025-02-24 7:03 ` Yu Kuai
2025-02-24 8:56 ` Ming Lei
2025-02-24 12:03 ` Yu Kuai
2025-02-25 1:24 ` Ming Lei
2025-02-25 2:07 ` Yu Kuai
2025-02-25 2:28 ` Ming Lei [this message]
2025-02-25 3:12 ` Yu Kuai
2025-02-25 8:21 ` Ming Lei
2025-02-25 11:09 ` Yu Kuai
2025-02-25 12:00 ` Ming Lei
2025-02-25 10:51 ` [PATCH 0/2] " Michal Koutný
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=Z70qvZEBdq6L3-Yb@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai1@huaweicloud.com \
--cc=yukuai3@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;
as well as URLs for NNTP newsgroup(s).