Commits
Jens Axboe authored and Konstantin Khorenko committed 785b8b84150
ms/block: hook up writeback throttling Enable throttling of buffered writeback to make it a lot more smooth, and has way less impact on other system activity. Background writeback should be, by definition, background activity. The fact that we flush huge bundles of it at the time means that it potentially has heavy impacts on foreground workloads, which isn't ideal. We can't easily limit the sizes of writes that we do, since that would impact file system layout in the presence of delayed allocation. So just throttle back buffered writeback, unless someone is waiting for it. The algorithm for when to throttle takes its inspiration in the CoDel networking scheduling algorithm. Like CoDel, blk-wb monitors the minimum latencies of requests over a window of time. In that window of time, if the minimum latency of any request exceeds a given target, then a scale count is incremented and the queue depth is shrunk. The next monitoring window is shrunk accordingly. Unlike CoDel, if we hit a window that exhibits good behavior, then we simply increment the scale count and re-calculate the limits for that scale value. This prevents us from oscillating between a close-to-ideal value and max all the time, instead remaining in the windows where we get good behavior. Unlike CoDel, blk-wb allows the scale count to to negative. This happens if we primarily have writes going on. Unlike positive scale counts, this doesn't change the size of the monitoring window. When the heavy writers finish, blk-bw quickly snaps back to it's stable state of a zero scale count. The patch registers a sysfs entry, 'wb_lat_usec'. This sets the latency target to me met. It defaults to 2 msec for non-rotational storage, and 75 msec for rotational storage. Setting this value to '0' disables blk-wb. Generally, a user would not have to touch this setting. We don't enable WBT on devices that are managed with CFQ, and have a non-root block cgroup attached. If we have a proportional share setup on this particular disk, then the wbt throttling will interfere with that. We don't have a strong need for wbt for that case, since we will rely on CFQ doing that for us. Signed-off-by: Jens Axboe <axboe@fb.com> https://jira.sw.ru/browse/PSBM-96243 (cherry picked from commit 87760e5eef359788047d6fd54fc12eec74ce0d27) Also merged non block/blk-wbt* hunks of previous patch from: 8054b89f8fca ("blk-wbt: remove stat ops")), fa224eed2b5e ("blk-wbt: cleanup disable-by-default for CFQ"), a8a45941706b ("block: pass struct request instead of struct blk_issue_stat to wbt") Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> ===================== Patchset description: block: backport writeback throttling We have a problem that if we run heavy write load on one cpu simultaneousely with short direct reads on other cpu, the latter will hang significantly. Writeback throttling looks like a sollution for these reads, as it will decrease the priority of long running writeback. Running simple dd experiment we see that reads latency decreased after wbt patches applied: https://docs.google.com/spreadsheets/d/1HLtepwFL_N5zm0JcTqMtJoYnf-b6Slwld8DDgL0gNDI We've ran vconsolidate on custom kernel with these patches, though it does not show any performance improvement (likely because this test does not produce high rate of writeback), it does not crash or fail the test. https://jira.sw.ru/browse/PSBM-96243 Jens Axboe (6): block: add REQ_BACKGROUND writeback: add wbc_to_write_flags() writeback: mark background writeback as such writeback: track if we're sleeping on progress in balance_dirty_pages() blk-wbt: add general throttling mechanism block: hook up writeback throttling Omar Sandoval (1): block: get rid of struct blk_issue_stat Pavel Tikhomirov (2): x86/asm: remove the unused get_limit() method block: enable CONFIG_BLK_WBT* blk-wbt: increase maximum queue depth to increase performance of writes