Yes，this is absolutely our use case. We use bcache in our ceph clusters to boost osd performance. Some users(offline data analysis etc) periodly generate heavy IO pressure to the storage system and then sleep for several hours. Most of the IOPS are comsumed by those big users but we also have more amount of smaller userd with low IOPS requirement. We want to flush the dirty data when smaller users only online, so we can handle the bigger users when they come online. > 在 2018年11月26日，下午8:39，Vojtech Pavlik <vojtech@xxxxxxxx> 写道： > >> 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. > > -- > Vojtech Pavlik > Director SUSE Labs
