path: root/block/bfq-iosched.c
diff options
authorPaolo Valente <>2017-09-21 11:04:03 +0200
committerJens Axboe <>2017-10-03 08:40:58 -0600
commit7cb04004fa371a626c1a5ebe6d977f70285759ed (patch)
tree778641f8f8812fa778d7c35bdf5a3cbb7402fa87 /block/bfq-iosched.c
parent894df937e06a56ed6f054a75a416aff84147c5a2 (diff)
block, bfq: decrease burst size when queues in burst exit
If many queues belonging to the same group happen to be created shortly after each other, then the concurrent processes associated with these queues have typically a common goal, and they get it done as soon as possible if not hampered by device idling. Examples are processes spawned by git grep, or by systemd during boot. As for device idling, this mechanism is currently necessary for weight raising to succeed in its goal: privileging I/O. In view of these facts, BFQ does not provide the above queues with either weight raising or device idling. On the other hand, a burst of queue creations may be caused also by the start-up of a complex application. In this case, these queues need usually to be served one after the other, and as quickly as possible, to maximise responsiveness. Therefore, in this case the best strategy is to weight-raise all the queues created during the burst, i.e., the exact opposite of the strategy for the above case. To distinguish between the two cases, BFQ uses an empirical burst-size threshold, found through extensive tests and monitoring of daily usage. Only large bursts, i.e., burst with a size above this threshold, are considered as generated by a high number of parallel processes. In this respect, upstart-based boot proved to be rather hard to detect as generating a large burst of queue creations, because with upstart most of the queues created in a burst exit *before* the next queues in the same burst are created. To address this issue, I changed the burst-detection mechanism so as to not decrease the size of the current burst even if one of the queues in the burst is eliminated. Unfortunately, this missing decrease causes false positives on very fast systems: on the start-up of a complex application, such as libreoffice writer, so many queues are created, served and exited shortly after each other, that a large burst of queue creations is wrongly detected as occurring. These false positives just disappear if the size of a burst is decreased when one of the queues in the burst exits. This commit restores the missing burst-size decrease, relying of the fact that upstart is apparently unlikely to be used on systems running this and future versions of the kernel. Signed-off-by: Paolo Valente <> Signed-off-by: Mauro Andreolini <> Signed-off-by: Angelo Ruocco <> Tested-by: Mirko Montanari <> Tested-by: Oleksandr Natalenko <> Tested-by: Lee Tibbert <> Signed-off-by: Jens Axboe <>
Diffstat (limited to 'block/bfq-iosched.c')
1 files changed, 3 insertions, 9 deletions
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 115747f..70f9177 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -3725,16 +3725,10 @@ void bfq_put_queue(struct bfq_queue *bfqq)
if (bfqq->ref)
- if (bfq_bfqq_sync(bfqq))
- /*
- * The fact that this queue is being destroyed does not
- * invalidate the fact that this queue may have been
- * activated during the current burst. As a consequence,
- * although the queue does not exist anymore, and hence
- * needs to be removed from the burst list if there,
- * the burst size has not to be decremented.
- */
+ if (bfq_bfqq_sync(bfqq) && !hlist_unhashed(&bfqq->burst_list_node)) {
+ bfqq->bfqd->burst_size--;
+ }
kmem_cache_free(bfq_pool, bfqq);