Coly--
On 10/07/2017 09:22 PM, Coly Li wrote:
[snip]
rate: 488.2M/sec
dirty: 91.7G
target: 152.3G
proportional: -1.5G
integral: 10.9G
change: 0.0k/sec
next io: 0ms
[snip]
The backing cached device size is 7.2TB, cache device is 1.4TB, block
size is 8kB only. I write 700G (50% of cache device size) dirty data
onto the cache device, and start writeback by echo 1 to
writeback_running file.
In my test, writeback spent 89 minutes to decrease dirty number from
700G to 147G (dirty target number is 152G). At this moment writeback
rate was still displayed as 488.2M/sec. And after 22 minutes writeback
rate jumped to 4.0k/sec. During the 22 minutes, (147-15.8=) 131.2G dirty
data written out.
I see it-- if we can write faster than 488MB/sec, we inappropriately
clamp the write rate to 488MB/sec-- this is from the old code. In turn,
if we're keeping up at that speed, the integral term can wind up. I
will fix this and clean up a couple related things.
Is it as expected ?
It is supposed to overshoot the target, but not by this much.
I think the implementation must have changed at some point in the past
for bch_ratelimit, because the clamping doesn't match. bch_ratelimit
really needs a rewrite for other reasons, but I'll send the minimal fix now.
Thanks.
Mike
