From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48214) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6DGO-0001pL-2Y for qemu-devel@nongnu.org; Tue, 20 Sep 2011 23:14:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R6DGM-0007HX-KS for qemu-devel@nongnu.org; Tue, 20 Sep 2011 23:14:20 -0400 Received: from mail-wy0-f175.google.com ([74.125.82.175]:55402) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6DGM-0007HG-Fb for qemu-devel@nongnu.org; Tue, 20 Sep 2011 23:14:18 -0400 Received: by wyh5 with SMTP id 5so1717774wyh.34 for ; Tue, 20 Sep 2011 20:14:17 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110920123454.GA26235@amt.cnet> References: <1315476668-19812-1-git-send-email-wuzhy@linux.vnet.ibm.com> <1315476668-19812-4-git-send-email-wuzhy@linux.vnet.ibm.com> <20110909144403.GB19459@amt.cnet> <20110914105024.GA18910@amt.cnet> <20110920123454.GA26235@amt.cnet> Date: Wed, 21 Sep 2011 11:14:17 +0800 Message-ID: From: Zhi Yong Wu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v8 3/4] block: add block timer and throttling algorithm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: kwolf@redhat.com, aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, Zhi Yong Wu , qemu-devel@nongnu.org, pair@us.ibm.com, ryanh@us.ibm.com On Tue, Sep 20, 2011 at 8:34 PM, Marcelo Tosatti wrot= e: > On Mon, Sep 19, 2011 at 05:55:41PM +0800, Zhi Yong Wu wrote: >> On Wed, Sep 14, 2011 at 6:50 PM, Marcelo Tosatti w= rote: >> > On Tue, Sep 13, 2011 at 11:09:46AM +0800, Zhi Yong Wu wrote: >> >> On Fri, Sep 9, 2011 at 10:44 PM, Marcelo Tosatti wrote: >> >> > On Thu, Sep 08, 2011 at 06:11:07PM +0800, Zhi Yong Wu wrote: >> >> >> Note: >> >> >> =A0 =A0 =A01.) When bps/iops limits are specified to a small value= such as 511 bytes/s, this VM will hang up. We are considering how to handl= e this senario. >> >> > >> >> > You can increase the length of the slice, if the request is larger = than >> >> > slice_time * bps_limit. >> >> Yeah, but it is a challenge for how to increase it. Do you have some = nice idea? >> > >> > If the queue is empty, and the request being processed does not fit th= e >> > queue, increase the slice so that the request fits. >> Sorry for late reply. actually, do you think that this scenario is >> meaningful for the user? >> Since we implement this, if the user limits the bps below 512 >> bytes/second, the VM can also not run every task. >> Can you let us know why we need to make such effort? > > It would be good to handle request larger than the slice. OK. Let me spend some time on trying your way. > > It is not strictly necessary, but in case its not handled, a minimum > should be in place, to reflect maximum request size known. Being able to In fact, slice_time has been dynamic now, and adjusted in some range. > specify something which crashes is not acceptable. Do you mean that one warning should be displayed if the specified limit is smaller than the minimum capability? > > --=20 Regards, Zhi Yong Wu