summaryrefslogtreecommitdiffstats
path: root/block/bfq-iosched.h
diff options
context:
space:
mode:
authorPaolo Valente <paolo.valente@linaro.org>2019-03-12 09:59:32 +0100
committerJens Axboe <axboe@kernel.dk>2019-04-01 08:15:40 -0600
commit84a746891e1d8364485c0a37533fe6c1380270d4 (patch)
treebe0f13d6535b28954b05e2769f04ec311949e98e /block/bfq-iosched.h
parent7074f076ff153021f408229b0ce63063dde9a400 (diff)
downloadlinux-84a746891e1d8364485c0a37533fe6c1380270d4.tar.gz
linux-84a746891e1d8364485c0a37533fe6c1380270d4.tar.bz2
linux-84a746891e1d8364485c0a37533fe6c1380270d4.zip
block, bfq: always protect newly-created queues from existing active queues
If many bfq_queues belonging to the same group happen to be created shortly after each other, then the processes associated with these queues have typically a common goal. In particular, bursts of queue creations are usually caused by services or applications that spawn many parallel threads/processes. Examples are systemd during boot, or git grep. If there are no other active queues, then, to help these processes get their job done as soon as possible, the best thing to do is to reach a high throughput. To this goal, it is usually better to not grant either weight-raising or device idling to the queues associated with these processes. And this is exactly what BFQ currently does. There is however a drawback: if, in contrast, some other queues are already active, then the newly created queues must be protected from the I/O flowing through the already existing queues. In this case, the best thing to do is the opposite as in the other case: it is much better to grant weight-raising and device idling to the newly-created queues, if they deserve it. This commit addresses this issue by doing so if there are already other active queues. This change also helps eliminating false positives, which occur when the newly-created queues do not belong to an actual large burst of creations, but some background task (e.g., a service) happens to trigger the creation of new queues in the middle, i.e., very close to when the victim queues are created. These false positive may cause total loss of control on process latencies. Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Paolo Valente <paolo.valente@linaro.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'block/bfq-iosched.h')
0 files changed, 0 insertions, 0 deletions