From mboxrd@z Thu Jan  1 00:00:00 1970
From: Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [Qemu-devel] [RFC]QEMU disk I/O limits
Date: Wed, 1 Jun 2011 09:20:35 -0400
Message-ID: <20110601132035.GA21638@redhat.com>
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>
 <20110531192434.GK16382@redhat.com>
 <4DE57A01.1070205@codemonkey.ws>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kwolf@redhat.com, stefanha@linux.vnet.ibm.com,
	Mike Snitzer <snitzer@redhat.com>, guijianfeng@cn.fujitsu.com,
	qemu-devel@nongnu.org, wuzhy@cn.ibm.com,
	herbert@gondor.hengli.com.au, Joe Thornber <ejt@redhat.com>,
	Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>, luowenj@cn.ibm.com,
	kvm@vger.kernel.org, zhanx@cn.ibm.com, zhaoyang@cn.ibm.com,
	llim@redhat.com, Ryan A Harper <raharper@us.ibm.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:43523 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753989Ab1FANU4 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 1 Jun 2011 09:20:56 -0400
Content-Disposition: inline
In-Reply-To: <4DE57A01.1070205@codemonkey.ws>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Tue, May 31, 2011 at 06:30:09PM -0500, Anthony Liguori wrote:

[..]
> The level of consistency will then depend on whether you overcommit
> your hardware and how you have it configured.

Agreed.

> 
> Consistency is very hard because at the end of the day, you still
> have shared resources.  Even with blkio, I presume one guest can
> still impact another guest by forcing the disk to do excessive
> seeking or something of that nature.
> 
> So absolutely consistency can't be the requirement for the use-case.
> The use-cases we are interested really are more about providing caps
> than anything else.

I think both qemu and kenrel can do the job. The only thing which
seriously favors throttling implementation in qemu is the ability
to handle wide variety of backend files (NFS, qcow, libcurl based
devices etc).

So what I am arguing is that your previous reason that qemu can do
a better job because it knows effective IOPS of guest, is not
necessarily a very good reason. To me simplicity of being able to handle
everything as file and do the throttling is the most compelling reason
to do this implementation in qemu.

Thanks
Vivek