From patchwork Thu Mar 21 14:28:57 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Beno=C3=AEt_Canet?= X-Patchwork-Id: 229704 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id E1EF32C00CB for ; Fri, 22 Mar 2013 01:29:06 +1100 (EST) Received: from localhost ([::1]:52230 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIgUH-0003AX-ES for incoming@patchwork.ozlabs.org; Thu, 21 Mar 2013 10:29:01 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIgTk-00038y-FK for qemu-devel@nongnu.org; Thu, 21 Mar 2013 10:28:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIgTX-0003wh-A9 for qemu-devel@nongnu.org; Thu, 21 Mar 2013 10:28:23 -0400 Received: from nodalink.pck.nerim.net ([62.212.105.220]:34190 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIgTW-0003sm-Vq for qemu-devel@nongnu.org; Thu, 21 Mar 2013 10:28:15 -0400 Received: by paradis.irqsave.net (Postfix, from userid 1002) id 8478887434E; Thu, 21 Mar 2013 15:28:00 +0100 (CET) Received: from irqsave.net (unknown [192.168.77.1]) by paradis.irqsave.net (Postfix) with ESMTP id CC01F874186; Thu, 21 Mar 2013 15:27:51 +0100 (CET) Date: Thu, 21 Mar 2013 15:28:57 +0100 From: =?iso-8859-1?Q?Beno=EEt?= Canet To: Stefan Hajnoczi Message-ID: <20130321142856.GA4259@irqsave.net> References: <1363770734-30970-1-git-send-email-benoit@irqsave.net> <1363770734-30970-2-git-send-email-benoit@irqsave.net> <20130320132924.GB14441@stefanha-thinkpad.muc.redhat.com> <20130320142842.GA2389@stefanha-thinkpad.muc.redhat.com> <20130320152714.GB1473@irqsave.net> <20130321103453.GB12555@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130321103453.GB12555@stefanha-thinkpad.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 62.212.105.220 Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , kwolf@redhat.com, wuzhy@linux.vnet.ibm.com, qemu-devel@nongnu.org, Stefan Hajnoczi Subject: Re: [Qemu-devel] [PATCH] block: fix bdrv_exceed_iops_limits wait computation X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org The +1 was here to account the current request as already done in this slice. Statistically there is 50% chance that it will be wrong. I toyed adding + 0.5 add wait_time doesn't drift anymore while iops don't oscillate. } else { I will let a vm run this patch for a while Regards Benoît > Le Thursday 21 Mar 2013 à 11:34:53 (+0100), Stefan Hajnoczi a écrit : > 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 > diff --git a/block.c b/block.c index 0a062c9..455d8b0 100644 --- a/block.c +++ b/block.c @@ -3739,7 +3739,7 @@ static bool bdrv_exceed_iops_limits(BlockDriverState *bs, bool is_write, } /* Calc approx time to dispatch */ - wait_time = (ios_base + 1) / iops_limit; + wait_time = (ios_base + 0.5) / iops_limit; if (wait_time > elapsed_time) { wait_time = wait_time - elapsed_time;