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
