aboutsummaryrefslogtreecommitdiff
path: root/block/stream.c
diff options
context:
space:
mode:
authorSascha Silbe <silbe@linux.vnet.ibm.com>2016-06-28 17:28:41 +0200
committerMax Reitz <mreitz@redhat.com>2016-07-13 13:41:38 +0200
commitf14a39ccb922ee123741ae2cf70a10eef9a650fc (patch)
tree308b6a882e86b9733952f20632564668e9689fd8 /block/stream.c
parentc834cba90521576224c30b15ebb4d6aeab7b42c4 (diff)
downloadqemu-f14a39ccb922ee123741ae2cf70a10eef9a650fc.zip
qemu-f14a39ccb922ee123741ae2cf70a10eef9a650fc.tar.gz
qemu-f14a39ccb922ee123741ae2cf70a10eef9a650fc.tar.bz2
Improve block job rate limiting for small bandwidth values
ratelimit_calculate_delay() previously reset the accounting every time slice, no matter how much data had been processed before. This had (at least) two consequences: 1. The minimum speed is rather large, e.g. 5 MiB/s for commit and stream. Not sure if there are real-world use cases where this would be a problem. Mirroring and backup over a slow link (e.g. DSL) would come to mind, though. 2. Tests for block job operations (e.g. cancel) were rather racy All block jobs currently use a time slice of 100ms. That's a reasonable value to get smooth output during regular operation. However this also meant that the state of block jobs changed every 100ms, no matter how low the configured limit was. On busy hosts, qemu often transferred additional chunks until the test case had a chance to cancel the job. Fix the block job rate limit code to delay for more than one time slice to address the above issues. To make it easier to handle oversized chunks we switch the semantics from returning a delay _before_ the current request to a delay _after_ the current request. If necessary, this delay consists of multiple time slice units. Since the mirror job sends multiple chunks in one go even if the rate limit was exceeded in between, we need to keep track of the start of the current time slice so we can correctly re-compute the delay for the updated amount of data. The minimum bandwidth now is 1 data unit per time slice. The block jobs are currently passing the amount of data transferred in sectors and using 100ms time slices, so this translates to 5120 bytes/second. With chunk sizes usually being O(512KiB), tests have plenty of time (O(100s)) to operate on block jobs. The chance of a race condition now is fairly remote, except possibly on insanely loaded systems. Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com> Message-id: 1467127721-9564-2-git-send-email-silbe@linux.vnet.ibm.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Diffstat (limited to 'block/stream.c')
-rw-r--r--block/stream.c12
1 files changed, 4 insertions, 8 deletions
diff --git a/block/stream.c b/block/stream.c
index 2e7c654..3187481 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -95,6 +95,7 @@ static void coroutine_fn stream_run(void *opaque)
BlockDriverState *base = s->base;
int64_t sector_num = 0;
int64_t end = -1;
+ uint64_t delay_ns = 0;
int error = 0;
int ret = 0;
int n = 0;
@@ -123,10 +124,8 @@ static void coroutine_fn stream_run(void *opaque)
}
for (sector_num = 0; sector_num < end; sector_num += n) {
- uint64_t delay_ns = 0;
bool copy;
-wait:
/* Note that even when no rate limit is applied we need to yield
* with no pending I/O here so that bdrv_drain_all() returns.
*/
@@ -156,12 +155,6 @@ wait:
}
trace_stream_one_iteration(s, sector_num, n, ret);
if (copy) {
- if (s->common.speed) {
- delay_ns = ratelimit_calculate_delay(&s->limit, n);
- if (delay_ns > 0) {
- goto wait;
- }
- }
ret = stream_populate(blk, sector_num, n, buf);
}
if (ret < 0) {
@@ -182,6 +175,9 @@ wait:
/* Publish progress */
s->common.offset += n * BDRV_SECTOR_SIZE;
+ if (copy && s->common.speed) {
+ delay_ns = ratelimit_calculate_delay(&s->limit, n);
+ }
}
if (!base) {