qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] block: fix bdrv_exceed_iops_limits wait computa


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH] block: fix bdrv_exceed_iops_limits wait computation
Date: Thu, 21 Mar 2013 11:34:53 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Mar 20, 2013 at 04:27:14PM +0100, Benoît Canet wrote:
> > Now there is no oscillation and the wait_times do not grow or shrink
> > under constant load from dd(1).
> >
> > Can you try this patch by itself to see if it fixes the oscillation?
> 
> On my test setup it fixes the oscillation and lead to an average 149.88 iops.
> However another pattern appear.
> iostat -d 1 -x will show something between 150 and 160 iops for several sample
> then a sample would show around 70 iops to compensate for the additional ios
> and this cycle restart.

I've begun drilling down on these fluctuations.

I think the problem is that I/O throttling uses bdrv_acct_done()
accounting.  bdrv_acct_done is only called when requests complete.  This
has the following problem:

Number of IOPS in this slice @ 150 IOPS = 15 ops per 100 ms slice

14 ops have completed already, only 1 more can proceed.

3 ops arrive in rapid succession:

Op #1: Allowed through since 1 op can proceed.  We submit the op.
Op #2: Allowed through since op #1 is still in progress so
       bdrv_acct_done() has not been called yet.
Op #3: Allowed through since op #1 & #2 are still in progress so
       bdrv_acct_done() has not been called yet.

Now when the ops start completing and the slice is extended we end up
with weird wait times since we overspent our budget.

I'm going to try a fix for delayed accounting.  Will report back with
patches if it is successful.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]