qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] block I/O throttling: how to enable in libvirt


From: Gui Jianfeng
Subject: Re: [Qemu-devel] [RFC] block I/O throttling: how to enable in libvirt
Date: Fri, 02 Sep 2011 09:16:59 +0800
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0

On 2011-9-1 16:11, Stefan Hajnoczi wrote:
> On Thu, Sep 01, 2011 at 01:05:31PM +0800, Zhi Yong Wu wrote:
>> On Wed, Aug 31, 2011 at 08:18:19AM +0100, Stefan Hajnoczi wrote:
>>> On Tue, Aug 30, 2011 at 2:46 PM, Adam Litke <address@hidden> wrote:
>>>> On Tue, Aug 30, 2011 at 09:53:33AM +0100, Stefan Hajnoczi wrote:
>>>>> I/O throttling can be applied independently to each -drive attached to
>>>>> a guest and supports throughput/iops limits.  For more information on
>>>>> this QEMU feature and a comparison with blkio-controller, see Ryan
>>>>> Harper's KVM Forum 2011 presentation:
>>>>
>>>>> http://www.linux-kvm.org/wiki/images/7/72/2011-forum-keep-a-limit-on-it-io-throttling-in-qemu.pdf
>>>>
>>>> From the presentation, it seems that both the cgroups method the the qemu 
>>>> method
>>>> offer comparable control (assuming a block device) so it might possible to 
>>>> apply
>>>> either method from the same API in a transparent manner.  Am I correct or 
>>>> are we
>>>> suggesting that the Qemu throttling approach should always be used for Qemu
>>>> domains?
>>>
>>> QEMU I/O throttling does not provide a proportional share mechanism.
>>> So you cannot assign weights to VMs and let them receive a fraction of
>>> the available disk time.  That is only supported by cgroups
>>> blkio-controller because it requires a global view which QEMU does not
>>> have.
>>>
>>> So I think the two are complementary:
>>>
>>> If proportional share should be used on a host block device, use
>>> cgroups blkio-controller.
>>> Otherwise use QEMU I/O throttling.
>> Stefan,
>>
>> Do you agree with introducing one new libvirt command blkiothrottle now?
>> If so, i will work on the code draft to make it work.
> 
> No, I think that the blkiotune command should be extended to support
> QEMU I/O throttling.  This is not new functionality, we already have
> cgroups blkio-controller support today.  Therefore I think it makes
> sense to keep a unified interface instead of adding a new command.

Agreed.
Proportional controlling interfaces and throttling interfaces are all
the same cgroup subsystem. So Just extend blkiotune to add new options
to support throttling tuning.

Thanks,
Gui

> 
> Stefan
> 
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]