From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhi Yong Wu Subject: Re: [PATCH v8 3/4] block: add block timer and throttling algorithm Date: Mon, 19 Sep 2011 17:55:41 +0800 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Zhi Yong Wu , qemu-devel@nongnu.org, kvm@vger.kernel.org, stefanha@linux.vnet.ibm.com, aliguori@us.ibm.com, ryanh@us.ibm.com, kwolf@redhat.com, pair@us.ibm.com To: Marcelo Tosatti Return-path: Received: from mail-ww0-f44.google.com ([74.125.82.44]:49886 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754042Ab1ISJzn convert rfc822-to-8bit (ORCPT ); Mon, 19 Sep 2011 05:55:43 -0400 Received: by wwf22 with SMTP id 22so7735194wwf.1 for ; Mon, 19 Sep 2011 02:55:42 -0700 (PDT) In-Reply-To: <20110914105024.GA18910@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Sep 14, 2011 at 6:50 PM, Marcelo Tosatti = wrote: > 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 valu= e such as 511 bytes/s, this VM will hang up. We are considering how to = handle 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 t= he > 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? > > That is, make BLOCK_IO_SLICE_TIME dynamic and adjust it as described > above (if the bps or io limits change, reset it to the default > BLOCK_IO_SLICE_TIME). > >> >> =A0 =A0 =A02.) When "dd" command is issued in guest, if its optio= n bs is set to a large value such as "bs=3D1024K", the result speed wil= l slightly bigger than the limits. >> > >> > Why? >> This issue has not existed. I will remove it. >> When drive bps=3D1000000, i did some testings on guest VM. >> 1.) bs=3D1024K >> 18+0 records in >> 18+0 records out >> 18874368 bytes (19 MB) copied, 26.6268 s, 709 kB/s >> 2.) bs=3D2048K >> 18+0 records in >> 18+0 records out >> 37748736 bytes (38 MB) copied, 46.5336 s, 811 kB/s >> >> > >> > There is lots of debugging leftovers in the patch. >> sorry, i forgot to remove them. >> > >> > > > --=20 Regards, Zhi Yong Wu From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5aZl-0004MV-2u for qemu-devel@nongnu.org; Mon, 19 Sep 2011 05:55:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5aZj-0007Uz-Qy for qemu-devel@nongnu.org; Mon, 19 Sep 2011 05:55:45 -0400 Received: from mail-ww0-f53.google.com ([74.125.82.53]:58606) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5aZj-0007Un-MN for qemu-devel@nongnu.org; Mon, 19 Sep 2011 05:55:43 -0400 Received: by wwg14 with SMTP id 14so6721568wwg.10 for ; Mon, 19 Sep 2011 02:55:42 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110914105024.GA18910@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> Date: Mon, 19 Sep 2011 17:55:41 +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 Wed, Sep 14, 2011 at 6:50 PM, Marcelo Tosatti wrot= e: > 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 w= rote: >> > 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 su= ch as 511 bytes/s, this VM will hang up. We are considering how to handle t= his senario. >> > >> > You can increase the length of the slice, if the request is larger tha= n >> > slice_time * bps_limit. >> Yeah, but it is a challenge for how to increase it. Do you have some nic= e idea? > > If the queue is empty, and the request being processed does not fit the > 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? > > That is, make BLOCK_IO_SLICE_TIME dynamic and adjust it as described > above (if the bps or io limits change, reset it to the default > BLOCK_IO_SLICE_TIME). > >> >> =A0 =A0 =A02.) When "dd" command is issued in guest, if its option bs= is set to a large value such as "bs=3D1024K", the result speed will slight= ly bigger than the limits. >> > >> > Why? >> This issue has not existed. I will remove it. >> When drive bps=3D1000000, i did some testings on guest VM. >> 1.) bs=3D1024K >> 18+0 records in >> 18+0 records out >> 18874368 bytes (19 MB) copied, 26.6268 s, 709 kB/s >> 2.) bs=3D2048K >> 18+0 records in >> 18+0 records out >> 37748736 bytes (38 MB) copied, 46.5336 s, 811 kB/s >> >> > >> > There is lots of debugging leftovers in the patch. >> sorry, i forgot to remove them. >> > >> > > > --=20 Regards, Zhi Yong Wu