block: fix possible reorder of flush operations

This patch reduce CPU usage of flush operations a bit. When we have one
flush completed we should kick only next operation. We should not start
all pending operations in the hope that they will go back to wait on
wait_queue.

Also there is a technical possibility that requests will get reordered
with the previous approach. After wakeup all requests are removed from
the wait queue. They become active and they are processed one-by-one
adding to the wait queue in the same order. Though new flush can arrive
while all requests are not put into the queue.

Signed-off-by: Denis V. Lunev <den@openvz.org>
Tested-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com>
Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com>
Message-id: 1471457214-3994-3-git-send-email-den@openvz.org
CC: Stefan Hajnoczi <stefanha@redhat.com>
CC: Fam Zheng <famz@redhat.com>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Max Reitz <mreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

diff --git a/block/io.c b/block/io.c
index 9c04086286e396648d05bfdb8fd163b7e3cd846f..420944d80db104188445e198ce45eb890fc6edfb 100644 (file)
--- a/block/io.c
+++ b/block/io.c
@@ -2358,7 +2358,8 @@ out:
     /* Notify any pending flushes that we have completed */
     bs->flushed_gen = current_gen;
     bs->active_flush_req = NULL;
-    qemu_co_queue_restart_all(&bs->flush_queue);
+    /* Return value is ignored - it's ok if wait queue is empty */
+    qemu_co_queue_next(&bs->flush_queue);
 
     tracked_request_end(&req);
     return ret;