From: Alberto Garcia <berto@igalia.com>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Alberto Garcia <berto@igalia.com>,
qemu-block@nongnu.org, Markus Armbruster <armbru@redhat.com>,
Max Reitz <mreitz@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: [Qemu-devel] [PATCH 00/13] throttle: Allow I/O bursts for a user-defined period of time
Date: Fri, 5 Feb 2016 12:59:10 +0200 [thread overview]
Message-ID: <cover.1454669823.git.berto@igalia.com> (raw)
Hello everyone,
the current throttling code in QEMU allows limiting the I/O rate on
block devices. Limits can be set in operations per second (IOPS) or
bytes per second, allowing separate limits for read and write
operations on both cases.
In its basic usage the user can set a limit of, say, 100 IOPS on a
block device passing this option to -drive:
throttling.iops-total=100
In addition to that, QEMU can also allow the user to do I/O bursts
exceeding that limit up to a configurable rate:
throttling.iops-total=100,throttling.iops-total-max=2000
With this, the user can do a burst of 2000 IOPS before they're
throttled down to 100 IOPS. Then, after a sufficiently long period of
unused I/O they will be able to do a burst again.
This patch series introduces the possibility to do bursts for longer
period of times. A new setting called throttling.iops-total-max-length
is used to define for how long bursts can be sustained.
So adding throttling.iops-total-max-length=60 to the previous
configuration allows the user to do I/O at a rate of 2000 IOPS for 1
minute before going down to the base rate of 100 IOPS.
This is essentially the same as described in this AWS blog post:
https://aws.amazon.com/blogs/aws/new-ssd-backed-elastic-block-storage/
As described in the article, a use case for this feature is to allow
better performance when booting the OS or restarting a service while
keeping the average I/O limits lower the rest of the time.
Comments:
- There are 6 different settings for setting I/O limits: iops-total,
iops-read, iops-write, bps-total, bps-read, bps-write. This series
adds one new setting to set the length for each one of those.
I don't know if there's a good use case that requires such
fine-grained control. It's of course also possible to make it
simpler and add just one 'burst-length' setting that would apply
for all cases, but the current solution is IMHO simple enough and
consistent with the current API, and if we need to extend it later
the result is probably going to be ugly.
- With this series we set "a maximum of X operations/second for a
period of T seconds". If would also be possible to make it "a
maximum of X operations/second up to a total of Y operations". It
would be equivalent (Y = X * T) but I thought the current proposal
makes a more clear API.
And I think that's all.
Thanks!
Berto
Alberto Garcia (13):
throttle: Make throttle_compute_timer() static
throttle: Make throttle_conflicting() set errp
throttle: Make throttle_max_is_missing_limit() set errp
throttle: Make throttle_is_valid() set errp
throttle: Set always an average value when setting a maximum value
throttle: Merge all functions that check the configuration into one
throttle: Use throttle_config_init() to initialize ThrottleConfig
throttle: Add support for burst periods
throttle: Add command-line settings to define the burst periods
qapi: Add burst length parameters to block_set_io_throttle
qapi: Add burst length fields to BlockDeviceInfo
throttle: Check that burst_level leaks correctly
throttle: Test throttle_compute_wait() during bursts
block/qapi.c | 20 ++++++++
blockdev.c | 99 ++++++++++++++++++++++++++----------
hmp.c | 12 +++++
include/qemu/throttle.h | 55 ++++++++++++++------
qapi/block-core.json | 90 ++++++++++++++++++++++++++++-----
tests/test-throttle.c | 88 ++++++++++++++++++++++++--------
util/throttle.c | 132 ++++++++++++++++++++++++++++++++----------------
7 files changed, 377 insertions(+), 119 deletions(-)
--
2.7.0
next reply other threads:[~2016-02-05 11:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 10:59 Alberto Garcia [this message]
2016-02-05 10:59 ` [Qemu-devel] [PATCH 01/13] throttle: Make throttle_compute_timer() static Alberto Garcia
2016-02-05 10:59 ` [Qemu-devel] [PATCH 02/13] throttle: Make throttle_conflicting() set errp Alberto Garcia
2016-02-05 10:59 ` [Qemu-devel] [PATCH 03/13] throttle: Make throttle_max_is_missing_limit() " Alberto Garcia
2016-02-05 10:59 ` [Qemu-devel] [PATCH 04/13] throttle: Make throttle_is_valid() " Alberto Garcia
2016-02-05 10:59 ` [Qemu-devel] [PATCH 05/13] throttle: Set always an average value when setting a maximum value Alberto Garcia
2016-02-05 10:59 ` [Qemu-devel] [PATCH 06/13] throttle: Merge all functions that check the configuration into one Alberto Garcia
2016-02-05 10:59 ` [Qemu-devel] [PATCH 07/13] throttle: Use throttle_config_init() to initialize ThrottleConfig Alberto Garcia
2016-02-05 10:59 ` [Qemu-devel] [PATCH 08/13] throttle: Add support for burst periods Alberto Garcia
2016-02-16 10:45 ` Kevin Wolf
2016-02-16 14:24 ` Alberto Garcia
2016-02-05 10:59 ` [Qemu-devel] [PATCH 09/13] throttle: Add command-line settings to define the " Alberto Garcia
2016-02-05 10:59 ` [Qemu-devel] [PATCH 10/13] qapi: Add burst length parameters to block_set_io_throttle Alberto Garcia
2016-02-05 10:59 ` [Qemu-devel] [PATCH 11/13] qapi: Add burst length fields to BlockDeviceInfo Alberto Garcia
2016-02-05 10:59 ` [Qemu-devel] [PATCH 12/13] throttle: Check that burst_level leaks correctly Alberto Garcia
2016-02-05 10:59 ` [Qemu-devel] [PATCH 13/13] throttle: Test throttle_compute_wait() during bursts Alberto Garcia
2016-02-12 17:19 ` [Qemu-devel] [PATCH 00/13] throttle: Allow I/O bursts for a user-defined period of time Kevin Wolf
2016-02-12 21:50 ` Alberto Garcia
2016-02-15 16:40 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2016-02-16 15:38 ` Alberto Garcia
2016-02-17 9:42 ` 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=cover.1454669823.git.berto@igalia.com \
--to=berto@igalia.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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).