On 11/26/18 9:46 PM, wibrantwu wrote: > thanks for the warm help and looking forward to test the patches:) > I just realize there is already an option for minimum writeback rate. The sysfs file name is writeback_rate_minimum, it can be found from /sys/block/bcache0/bcache/, you may set a number (it is in sector size) as the minimum writeback rate, to make sure writeback thoughput is still large even backing device is idle but not idle enough to trigger max writeback rate (if you enable it). Could you please try it ? Then let's see if there is anything to fix. Thanks. Coly Li >> 在 2018年11月26日，下午9:24，Coly Li <colyli@xxxxxxx> 写道： >> >>> On 11/26/18 8:39 PM, Vojtech Pavlik wrote: >>>> On Mon, Nov 26, 2018 at 08:19:31PM +0800, Coly Li wrote: >>>>> On 11/26/18 7:55 PM, xingyi wu wrote: >>>>> hello guys, >>>>> We have upgraded kernel and found many exited optimizations in >>>>> writeback flow control, including set max writeback rate when the >>>>> backend device is idle. this is very helpful to keep a smaller size of >>>>> dirty data and when large amount of IO requests come, the caching system >>>>> can store more data. >>>>> But in our system, backend device is unlike to be totally idle >>>>> because our clients always keep sending IO requests to the frondend >>>>> device, even though sometimes the rate could be rather slow(like several >>>>> kb/s), in such case, the backend device is rather "idle" and we hope to >>>>> have higher writeback to keep smaller dirty data size. Does it make >>>>> sense? Is is possible to implement? Thanks. >>>>> >>>> >>>> It is possible to implement a minimum writeback rate, and let the >>>> minimum value of self-adopted writeback rate always being >= >>>> minimum_writeback_rate. >>>> >>>> But a larger writeback rate may increase regular I/O latency, so it is >>>> not recommended when there is no much dirty data. Could you please to >>>> provide a real case why you care about writeback performance more than >>>> regular I/O performance ? >>> >>> I assume this would be for a scenario where I/O comes in bursts of >>> activity interspersed by periods of idling. >>> >>> Increasing the writeback rate when there is not much happening on the >>> backend device (ie little activity overall, or all reads are cached) >>> would prepare the cache set better for the next burst by having the >>> cache mostly clean. >>> >> >> Yes it makes sense. Let me compose a patch for Xingyi to test, and see >> whether it works out :-) >> >> Coly Li
