On 2017/10/8 下午12:57, Michael Lyle wrote:

Coly--


On 10/07/2017 09:22 PM, Coly Li wrote:
[snip]

quoted

rate:        488.2M/sec
dirty:        91.7G
target:        152.3G
proportional:    -1.5G
integral:    10.9G
change:        0.0k/sec
next io:    0ms

[snip]

quoted

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.

quoted

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.

Hi Mike,

Copied, I will continue my test. And when the new version comes, I will
run same workload again to confirm.

Thanks.


-- 
Coly Li