From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRXKN-0004oS-Tw for qemu-devel@nongnu.org; Tue, 31 May 2011 18:22:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRXKM-0000iK-Bn for qemu-devel@nongnu.org; Tue, 31 May 2011 18:22:19 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:51255) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRXKL-0000iA-Bp for qemu-devel@nongnu.org; Tue, 31 May 2011 18:22:17 -0400 Received: by yib19 with SMTP id 19so2370926yib.4 for ; Tue, 31 May 2011 15:22:16 -0700 (PDT) Message-ID: <4DE56A15.3030804@codemonkey.ws> Date: Tue, 31 May 2011 17:22:13 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20110530050923.GF18832@f12.cn.ibm.com> <20110531134537.GE16382@redhat.com> <4DE4F230.2040203@us.ibm.com> <20110531140402.GF16382@redhat.com> <4DE4FA5B.1090804@codemonkey.ws> <20110531175955.GI16382@redhat.com> <4DE535F3.6040400@codemonkey.ws> <20110531204842.GA16832@redhat.com> In-Reply-To: <20110531204842.GA16832@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC]QEMU disk I/O limits List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mike Snitzer 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, Joe Thornber , Zhi Yong Wu , luowenj@cn.ibm.com, zhanx@cn.ibm.com, zhaoyang@cn.ibm.com, llim@redhat.com, Ryan A Harper , Vivek Goyal On 05/31/2011 03:48 PM, Mike Snitzer wrote: > On Tue, May 31 2011 at 2:39pm -0400, > Anthony Liguori wrote: > >>> Are you referring to merging taking place which can change the definition >>> of IOPS as seen by guest? >> >> No, with qcow2, it may take multiple real IOPs for what the guest >> sees as an IOP. >> >> That's really the main argument I'm making here. The only entity >> that knows what a guest IOP corresponds to is QEMU. On the backend, >> it may end up being a network request, multiple BIOs to physical >> disks, file access, etc. > > Couldn't QEMU give a hint to the kernel about the ratio of guest IOP to > real IOPs? Or is QEMU blind to the real IOPs that correspond to a guest > IOP? Perhaps, but how does that work when the disk image is backed by NFS? And even if you had a VFS level API, we can do things like libcurl based block devices in QEMU. So unless you tried to do level 5 traffic throttling which hopefully, you'll agree is total overkill, we're going to need to have this functionality in QEMU no matter what. Regards, Anthony Liguori