On Thu, Jun 02, 2011 at 09:17:06AM +0300, Sasha Levin wrote: >Date: Thu, 02 Jun 2011 09:17:06 +0300 >From: Sasha Levin <levinsasha...@gmail.com> >To: Zhi Yong Wu <wu...@linux.vnet.ibm.com> >Cc: qemu-de...@nongnu.org, kvm@vger.kernel.org, kw...@redhat.com, > aligu...@us.ibm.com, herb...@gondor.apana.org.au, > guijianf...@cn.fujitsu.com, wu...@cn.ibm.com, luow...@cn.ibm.com, > zh...@cn.ibm.com, zhaoy...@cn.ibm.com, l...@redhat.com, > rahar...@us.ibm.com, vgo...@redhat.com, stefa...@linux.vnet.ibm.com >Subject: Re: [Qemu-devel] [RFC]QEMU disk I/O limits >X-Mailer: Evolution 2.32.2 > >Hi, > >On Mon, 2011-05-30 at 13:09 +0800, Zhi Yong Wu wrote: >> Hello, all, >> >> I have prepared to work on a feature called "Disk I/O limits" for >> qemu-kvm projeect. >> This feature will enable the user to cap disk I/O amount performed by a >> VM.It is important for some storage resources to be shared among multi-VMs. >> As you've known, if some of VMs are doing excessive disk I/O, they will hurt >> the performance of other VMs. >> >> More detail is available here: >> http://wiki.qemu.org/Features/DiskIOLimits >> >> 1.) Why we need per-drive disk I/O limits >> As you've known, for linux, cgroup blkio-controller has supported I/O >> throttling on block devices. More importantly, there is no single mechanism >> for disk I/O throttling across all underlying storage types (image file, >> LVM, NFS, Ceph) and for some types there is no way to throttle at all. >> >> Disk I/O limits feature introduces QEMU block layer I/O limits together >> with command-line and QMP interfaces for configuring limits. This allows I/O >> limits to be imposed across all underlying storage types using a single >> interface. >> >> 2.) How disk I/O limits will be implemented >> QEMU block layer will introduce a per-drive disk I/O request queue for >> those disks whose "disk I/O limits" feature is enabled. It can control disk >> I/O limits individually for each disk when multiple disks are attached to a >> VM, and enable use cases like unlimited local disk access but shared storage >> access with limits. >> In mutliple I/O threads scenario, when an application in a VM issues a >> block I/O request, this request will be intercepted by QEMU block layer, >> then it will calculate disk runtime I/O rate and determine if it has go >> beyond its limits. If yes, this I/O request will enqueue to that introduced >> queue; otherwise it will be serviced. >> >> 3.) How the users enable and play with it >> QEMU -drive option will be extended so that disk I/O limits can be >> specified on its command line, such as -drive [iops=xxx,][throughput=xxx] or >> -drive [iops_rd=xxx,][iops_wr=xxx,][throughput=xxx] etc. When this argument >> is specified, it means that "disk I/O limits" feature is enabled for this >> drive disk. >> The feature will also provide users with the ability to change per-drive >> disk I/O limits at runtime using QMP commands. > >I'm wondering if you've considered adding a 'burst' parameter - >something which will not limit (or limit less) the io ops or the >throughput for the first 'x' ms in a given time window. Currently no, Do you let us know what scenario it will make sense to?
Regards, Zhiyong Wu > >> Regards, >> >> Zhiyong Wu >> > >-- > >Sasha. > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
