From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [Xen-users] Re: VM disk I/O limit patch Date: Wed, 22 Jun 2011 10:39:01 -0400 Message-ID: <20110622143901.GB6613@dumpdata.com> References: <20110622200623.8CE4.3A8D29D5@cloudex.cn> <20110622131121.GB8216@dumpdata.com> <20110622221248.8CF3.3A8D29D5@cloudex.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20110622221248.8CF3.3A8D29D5@cloudex.cn> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andrew Xu Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > > I am not convienced this will be easier to maintain than > > using existing code (dm-ioband) that Linux kernel provides already. > > > > Are there other technical reasons 'dm-ioband' is not sufficient > > enough? Could it be possible to fix 'dm-ioband' to not have those > > bugs? Florian mentioned flush requests not passing through > > the DM layers but I am pretty sure those have been fixed. > > > I don't find dm-ioband's bug, so I can't answer your question. > > But, xen-vm-disk I/O limitation shoud done by xen module, is not it? Not all I/O's for a guest go through the xen-blkback. For example the tap, qcow, are all inside of QEMU which has no notion of xen-blkback (this is upstream QEMU BTW) - so they would not benefit from this at all. While if all of the "disks" that are assigned to a guest go through dm-ioband the system admin has only one interface that can cover _all_ of the I/O sinks. And it is standard enough so that if that system admin is switching over from KVM to Xen they don't have to alter a lot of their infrastructure.