aboutsummaryrefslogtreecommitdiff
path: root/contrib/ivshmem-client
diff options
context:
space:
mode:
authorAlberto Garcia <berto@igalia.com>2017-08-24 16:24:44 +0300
committerStefan Hajnoczi <stefanha@redhat.com>2017-08-29 16:54:44 +0100
commit0770a7a6466cc2dbf4ac91841173ad4488e1fbc7 (patch)
tree1a0ae1fdda4118f1f3539971c08f71348da5680d /contrib/ivshmem-client
parentfaa8215c1778159803d6af9368b922d8ef61aee2 (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