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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
