diff options
author | Alberto Garcia <berto@igalia.com> | 2017-08-24 16:24:44 +0300 |
---|---|---|
committer | Stefan Hajnoczi <stefanha@redhat.com> | 2017-08-29 16:54:44 +0100 |
commit | 0770a7a6466cc2dbf4ac91841173ad4488e1fbc7 (patch) | |
tree | 1a0ae1fdda4118f1f3539971c08f71348da5680d /contrib/ivshmem-client | |
parent | faa8215c1778159803d6af9368b922d8ef61aee2 (diff) |
throttle: Update the throttle_fix_bucket() documentation
The way the throttling algorithm works is that requests start being
throttled once the bucket level exceeds the burst limit. When we get
there the bucket leaks at the level set by the user (bkt->avg), and
that leak rate is what prevents guest I/O from exceeding the desired
limit.
If we don't allow bursts (i.e. bkt->max == 0) then we can start
throttling requests immediately. The problem with keeping the
threshold at 0 is that it only allows one request at a time, and as
soon as there's a bit of I/O from the guest every other request will
be throttled and performance will suffer considerably. That can even
make the guest unable to reach the throttle limit if that limit is
high enough, and that happens regardless of the block scheduler used
by the guest.
Increasing that threshold gives flexibility to the guest, allowing it
to perform short bursts of I/O before being throttled. Increasing the
threshold too much does not make a difference in the long run (because
it's the leak rate what defines the actual throughput) but it does
allow the guest to perform longer initial bursts and exceed the
throttle limit for a short while.
A burst value of bkt->avg / 10 allows the guest to perform 100ms'
worth of I/O at the target rate without being throttled.
Signed-off-by: Alberto Garcia <berto@igalia.com>
Message-id: 31aae6645f0d1fbf3860fb2b528b757236f0c0a7.1503580370.git.berto@igalia.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Diffstat (limited to 'contrib/ivshmem-client')
0 files changed, 0 insertions, 0 deletions