From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Suchanek Subject: Re: [Qemu-devel] [RFC]QEMU disk I/O limits Date: Thu, 2 Jun 2011 11:33:44 +0200 Message-ID: References: <20110530050923.GF18832@f12.cn.ibm.com> <20110531195549.GL16382@redhat.com> <20110601031255.GG18832@f12.cn.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Vivek Goyal , kwolf@redhat.com, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, guijianfeng@cn.fujitsu.com, qemu-devel@nongnu.org, wuzhy@cn.ibm.com, herbert@gondor.hengli.com.au, ejt@redhat.com, luowenj@cn.ibm.com, zhanx@cn.ibm.com, zhaoyang@cn.ibm.com, llim@redhat.com, raharper@us.ibm.com To: Zhi Yong Wu Return-path: Received: from mail-px0-f179.google.com ([209.85.212.179]:57806 "EHLO mail-px0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932439Ab1FBJeF convert rfc822-to-8bit (ORCPT ); Thu, 2 Jun 2011 05:34:05 -0400 Received: by pxi2 with SMTP id 2so467853pxi.10 for ; Thu, 02 Jun 2011 02:34:04 -0700 (PDT) In-Reply-To: <20110601031255.GG18832@f12.cn.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On 1 June 2011 05:12, Zhi Yong Wu wrote: > On Tue, May 31, 2011 at 03:55:49PM -0400, Vivek Goyal wrote: >>Date: Tue, 31 May 2011 15:55:49 -0400 >>From: Vivek Goyal >>To: Zhi Yong Wu >>Cc: kwolf@redhat.com, aliguori@us.ibm.com, stefanha@linux.vnet.ibm.co= m, >> =C2=A0 =C2=A0 =C2=A0 kvm@vger.kernel.org, guijianfeng@cn.fujitsu.com= , >> =C2=A0 =C2=A0 =C2=A0 qemu-devel@nongnu.org, wuzhy@cn.ibm.com, >> =C2=A0 =C2=A0 =C2=A0 herbert@gondor.hengli.com.au, luowenj@cn.ibm.co= m, zhanx@cn.ibm.com, >> =C2=A0 =C2=A0 =C2=A0 zhaoyang@cn.ibm.com, llim@redhat.com, raharper@= us.ibm.com >>Subject: Re: [Qemu-devel] [RFC]QEMU disk I/O limits >>User-Agent: Mutt/1.5.21 (2010-09-15) >> >>On Mon, May 30, 2011 at 01:09:23PM +0800, Zhi Yong Wu wrote: >> >>[..] >>> =C2=A0 =C2=A0 3.) How the users enable and play with it >>> =C2=A0 =C2=A0 QEMU -drive option will be extended so that disk I/O = limits can be specified on its command line, such as -drive [iops=3Dxxx= ,][throughput=3Dxxx] or -drive [iops_rd=3Dxxx,][iops_wr=3Dxxx,][through= put=3Dxxx] etc. When this argument is specified, it means that "disk I/= O limits" feature is enabled for this drive disk. >> >>How does throughput interface look like? is it bytes per second or so= mething >>else? > HI, Vivek, > It will be a value based on bytes per second. > >> >>Do we have read and write variants for throughput as we have for iops= =2E > QEMU code has two variants "rd_bytes, wr_bytes", but we maybe need to= get their bytes per second. > >> >>if you have bytes interface(as kenrel does), then "bps_rd" and "bps_w= r" >>might be good names too for thoughput interface. > I agree with you, and can change them as your suggestions. > Changing them this way is not going to be an improvement. While rd_bytes and wr_bytes lack the time interval specification bps_rd and bps_wr is ambiguous. Is that bits? bytes? Sure, there should be some distinction by capitalization but that does not apply since qemu arguments are all lowercase. Thanks Michal From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QS4I3-0003xn-VS for qemu-devel@nongnu.org; Thu, 02 Jun 2011 05:34:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QS4I2-0007rv-DY for qemu-devel@nongnu.org; Thu, 02 Jun 2011 05:34:07 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:35387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QS4I2-0007rN-8f for qemu-devel@nongnu.org; Thu, 02 Jun 2011 05:34:06 -0400 Received: by pzk30 with SMTP id 30so343767pzk.4 for ; Thu, 02 Jun 2011 02:34:04 -0700 (PDT) MIME-Version: 1.0 Sender: hramrach@gmail.com In-Reply-To: <20110601031255.GG18832@f12.cn.ibm.com> References: <20110530050923.GF18832@f12.cn.ibm.com> <20110531195549.GL16382@redhat.com> <20110601031255.GG18832@f12.cn.ibm.com> From: Michal Suchanek Date: Thu, 2 Jun 2011 11:33:44 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC]QEMU disk I/O limits List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhi Yong Wu Cc: kwolf@redhat.com, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, guijianfeng@cn.fujitsu.com, qemu-devel@nongnu.org, wuzhy@cn.ibm.com, herbert@gondor.hengli.com.au, ejt@redhat.com, luowenj@cn.ibm.com, zhanx@cn.ibm.com, zhaoyang@cn.ibm.com, llim@redhat.com, raharper@us.ibm.com, Vivek Goyal On 1 June 2011 05:12, Zhi Yong Wu wrote: > On Tue, May 31, 2011 at 03:55:49PM -0400, Vivek Goyal wrote: >>Date: Tue, 31 May 2011 15:55:49 -0400 >>From: Vivek Goyal >>To: Zhi Yong Wu >>Cc: kwolf@redhat.com, aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, >> =C2=A0 =C2=A0 =C2=A0 kvm@vger.kernel.org, guijianfeng@cn.fujitsu.com, >> =C2=A0 =C2=A0 =C2=A0 qemu-devel@nongnu.org, wuzhy@cn.ibm.com, >> =C2=A0 =C2=A0 =C2=A0 herbert@gondor.hengli.com.au, luowenj@cn.ibm.com, z= hanx@cn.ibm.com, >> =C2=A0 =C2=A0 =C2=A0 zhaoyang@cn.ibm.com, llim@redhat.com, raharper@us.i= bm.com >>Subject: Re: [Qemu-devel] [RFC]QEMU disk I/O limits >>User-Agent: Mutt/1.5.21 (2010-09-15) >> >>On Mon, May 30, 2011 at 01:09:23PM +0800, Zhi Yong Wu wrote: >> >>[..] >>> =C2=A0 =C2=A0 3.) How the users enable and play with it >>> =C2=A0 =C2=A0 QEMU -drive option will be extended so that disk I/O limi= ts can be specified on its command line, such as -drive [iops=3Dxxx,][throu= ghput=3Dxxx] or -drive [iops_rd=3Dxxx,][iops_wr=3Dxxx,][throughput=3Dxxx] e= tc. When this argument is specified, it means that "disk I/O limits" featur= e is enabled for this drive disk. >> >>How does throughput interface look like? is it bytes per second or someth= ing >>else? > HI, Vivek, > It will be a value based on bytes per second. > >> >>Do we have read and write variants for throughput as we have for iops. > QEMU code has two variants "rd_bytes, wr_bytes", but we maybe need to get= their bytes per second. > >> >>if you have bytes interface(as kenrel does), then "bps_rd" and "bps_wr" >>might be good names too for thoughput interface. > I agree with you, and can change them as your suggestions. > Changing them this way is not going to be an improvement. While rd_bytes and wr_bytes lack the time interval specification bps_rd and bps_wr is ambiguous. Is that bits? bytes? Sure, there should be some distinction by capitalization but that does not apply since qemu arguments are all lowercase. Thanks Michal