From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [RFC]QEMU disk I/O limits Date: Tue, 31 May 2011 17:22:13 -0500 Message-ID: <4DE56A15.3030804@codemonkey.ws> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 To: Mike Snitzer Return-path: Received: from mail-gy0-f174.google.com ([209.85.160.174]:47599 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932762Ab1EaWWR (ORCPT ); Tue, 31 May 2011 18:22:17 -0400 Received: by gyd10 with SMTP id 10so1970132gyd.19 for ; Tue, 31 May 2011 15:22:16 -0700 (PDT) In-Reply-To: <20110531204842.GA16832@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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