Re: [Qemu-devel] [PATCH V7 0/5] Continuous Leaky Bucket Throttling

[Stefan Hajnoczi]

On Wed, Aug 28, 2013 at 05:07:16PM +0200, Benoît Canet wrote:
> This patchset implement continous leaky bucket throttling.
> 
> It use two requests queue to enable to do silly unbalanced throttling like
> block_set_io_throttle 0 0 0 0 6000 1
> 
> It use two timer to get the timer callbacks and the throttle.c code simple
> 
> in this version:
> 
> The throttling core is pretty solid and the surrouding of the patchset needs
> polish. (new options ...)

Here is my understanding of how the algorithm works:

There is a "max" burst value which is a guaranteed allowance.  If max is
100 units then you can always use up to 100 units without being
throttled.

After the max burst value has been exceeded, requests are throttled down
to the "avg" rate value.  The way it works is like this:

1. If the max hasn't been reached, allow the request through.
2. If the max has been reached, schedule a timer for when the bucket
   level comes back down to max.
3. Increment bucket level when the request is allowed through.
4. Drain bucket level according to avg rate as time passes.

The max burst value is set automatically to avg / 10 unless manually
overridden.  This is supposed to be guest CFQ scheduler friendly because
it lets the guest submit a full 100 millisecond CFQ slice's worth of
requests (not sure I fully understand this).

A few comments:

1. We keep modifying the timer in bdrv_io_limits_intercept() on each
   request even when it has already been set.  I think we'll set it to
   the same absolute timestamp, modulo numerical issues.  Should we
   avoid doing this?

2. bdrv_io_limits_resched() only wakes up requests of the same type
   (read/write).  Does this mean that BPS_TOTAL/IOPS_TOTAL requests
   will have to wait until the other request type timer expires instead
   of piggybacking on request completion?

   Is this a problem?  If no, then why piggyback on request completion
   at all since apparently it works fine when we don't wake up the other
   request type?

Stefan