On 08/24/2017 08:24 AM, Alberto Garcia wrote: > 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 <be...@igalia.com> > --- > util/throttle.c | 11 +++-------- > 1 file changed, 3 insertions(+), 8 deletions(-)
Reviewed-by: Eric Blake <ebl...@redhat.com> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
