On 2017/10/8 下午12:57, Michael Lyle wrote: > 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
