[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z70qvZEBdq6L3-Yb@fedora>
Date: Tue, 25 Feb 2025 10:28:13 +0800
From: Ming Lei <ming.lei@...hat.com>
To: Yu Kuai <yukuai1@...weicloud.com>
Cc: tj@...nel.org, josef@...icpanda.com, axboe@...nel.dk,
cgroups@...r.kernel.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, yi.zhang@...wei.com,
yangerkun@...wei.com, "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH 2/2] blk-throttle: fix off-by-one jiffies wait_time
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
Powered by blists - more mailing lists