thanks for the warm help and looking forward to test the patches:) > 在 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
