From: Stefan Hajnoczi <stefanha@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Kevin Wolf" <kwolf@redhat.com>,
"Benoît Canet" <benoit@irqsave.net>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Zhi Yong Wu" <wuzhy@cn.ibm.com>
Subject: [Qemu-devel] [RFC 2/4] block: keep I/O throttling slice time constant
Date: Thu, 21 Mar 2013 15:49:57 +0100 [thread overview]
Message-ID: <1363877399-16339-3-git-send-email-stefanha@redhat.com> (raw)
In-Reply-To: <1363877399-16339-1-git-send-email-stefanha@redhat.com>
It is not necessary to adjust the slice time at runtime. We already
extend the current slice in order to carry over accounting into the next
slice. Changing the actual slice time value introduces oscillations.
The guest may experience large changes in throughput or IOPS from one
moment to the next when slice times are adjusted.
Reported-by: Benoît Canet <benoit@irqsave.net>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
block.c | 19 +++++++++----------
blockdev.c | 1 -
include/block/block_int.h | 1 -
3 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/block.c b/block.c
index 31fb0b0..712f544 100644
--- a/block.c
+++ b/block.c
@@ -140,7 +140,6 @@ void bdrv_io_limits_disable(BlockDriverState *bs)
bs->slice_start = 0;
bs->slice_end = 0;
- bs->slice_time = 0;
}
static void bdrv_block_timer(void *opaque)
@@ -1325,7 +1324,6 @@ static void bdrv_move_feature_fields(BlockDriverState *bs_dest,
bs_dest->enable_write_cache = bs_src->enable_write_cache;
/* i/o timing parameters */
- bs_dest->slice_time = bs_src->slice_time;
bs_dest->slice_start = bs_src->slice_start;
bs_dest->slice_end = bs_src->slice_end;
bs_dest->slice_submitted = bs_src->slice_submitted;
@@ -3646,6 +3644,7 @@ static bool bdrv_exceed_bps_limits(BlockDriverState *bs, int nb_sectors,
bool is_write, double elapsed_time, uint64_t *wait)
{
uint64_t bps_limit = 0;
+ uint64_t extension;
double bytes_limit, bytes_base, bytes_res;
double slice_time, wait_time;
@@ -3694,8 +3693,10 @@ static bool bdrv_exceed_bps_limits(BlockDriverState *bs, int nb_sectors,
* info can be kept until the timer fire, so it is increased and tuned
* based on the result of experiment.
*/
- bs->slice_time = wait_time * BLOCK_IO_SLICE_TIME * 10;
- bs->slice_end += bs->slice_time - 3 * BLOCK_IO_SLICE_TIME;
+ extension = wait_time * NANOSECONDS_PER_SECOND;
+ extension = DIV_ROUND_UP(extension, BLOCK_IO_SLICE_TIME) *
+ BLOCK_IO_SLICE_TIME;
+ bs->slice_end += extension;
if (wait) {
*wait = wait_time * BLOCK_IO_SLICE_TIME * 10;
}
@@ -3747,8 +3748,8 @@ static bool bdrv_exceed_iops_limits(BlockDriverState *bs, bool is_write,
wait_time = 0;
}
- bs->slice_time = wait_time * BLOCK_IO_SLICE_TIME * 10;
- bs->slice_end += bs->slice_time - 3 * BLOCK_IO_SLICE_TIME;
+ /* Exceeded current slice, extend it by another slice time */
+ bs->slice_end += BLOCK_IO_SLICE_TIME;
if (wait) {
*wait = wait_time * BLOCK_IO_SLICE_TIME * 10;
}
@@ -3767,12 +3768,10 @@ static bool bdrv_exceed_io_limits(BlockDriverState *bs, int nb_sectors,
now = qemu_get_clock_ns(vm_clock);
if ((bs->slice_start < now)
&& (bs->slice_end > now)) {
- bs->slice_end = now + bs->slice_time;
+ bs->slice_end = now + BLOCK_IO_SLICE_TIME;
} else {
- bs->slice_time = 5 * BLOCK_IO_SLICE_TIME;
bs->slice_start = now;
- bs->slice_end = now + bs->slice_time;
-
+ bs->slice_end = now + BLOCK_IO_SLICE_TIME;
memset(&bs->slice_submitted, 0, sizeof(bs->slice_submitted));
}
diff --git a/blockdev.c b/blockdev.c
index 09f76b7..e5ead1f 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1065,7 +1065,6 @@ void qmp_block_set_io_throttle(const char *device, int64_t bps, int64_t bps_rd,
}
bs->io_limits = io_limits;
- bs->slice_time = BLOCK_IO_SLICE_TIME;
if (!bs->io_limits_enabled && bdrv_io_limits_enabled(bs)) {
bdrv_io_limits_enable(bs);
diff --git a/include/block/block_int.h b/include/block/block_int.h
index b461764..ec75802 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -247,7 +247,6 @@ struct BlockDriverState {
unsigned int copy_on_read_in_flight;
/* the time for latest disk I/O */
- int64_t slice_time;
int64_t slice_start;
int64_t slice_end;
BlockIOLimit io_limits;
--
1.8.1.4
next prev parent reply other threads:[~2013-03-21 14:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-21 14:49 [Qemu-devel] [RFC 0/4] block: fix I/O throttling oscillations Stefan Hajnoczi
2013-03-21 14:49 ` [Qemu-devel] [RFC 1/4] block: fix I/O throttling accounting blind spot Stefan Hajnoczi
2013-03-27 8:50 ` Zhi Yong Wu
2013-03-27 9:14 ` Stefan Hajnoczi
2013-03-27 12:49 ` Zhi Yong Wu
2013-03-21 14:49 ` Stefan Hajnoczi [this message]
2013-03-21 14:49 ` [Qemu-devel] [RFC 3/4] block: drop duplicated slice extension code Stefan Hajnoczi
2013-03-21 14:49 ` [Qemu-devel] [RFC 4/4] block: clean up I/O throttling wait_time code Stefan Hajnoczi
2013-03-21 15:27 ` [Qemu-devel] [RFC 0/4] block: fix I/O throttling oscillations Benoît Canet
2013-03-21 16:34 ` Stefan Hajnoczi
2013-03-27 12:55 ` Zhi Yong Wu
2013-04-04 12:15 ` Benoît Canet
2013-04-04 16:24 ` Kevin Wolf
2013-04-04 16:30 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1363877399-16339-3-git-send-email-stefanha@redhat.com \
--to=stefanha@redhat.com \
--cc=benoit@irqsave.net \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wuzhy@cn.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).