qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Bug 1483070] [NEW] VIRTIO Sequential Write IOPS limits


From: Alberto Garcia
Subject: Re: [Qemu-devel] [Bug 1483070] [NEW] VIRTIO Sequential Write IOPS limits not working
Date: Fri, 14 Aug 2015 08:26:27 +0200
User-agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/23.2.1 (i486-pc-linux-gnu)

On Fri 14 Aug 2015 01:34:50 AM CEST, Peter Lieven <address@hidden> wrote:

>>> IOPS limit does not work for VIRTIO devices if the disk workload is
>>> a sequential write.

>> This is probably due to I/O request merging:
>> 
>> Your benchmark application may generate 32 x 4KB write requests, but
>> they are merged by the virtio-blk device into just 1 x 128KB write
>> request.
>> 
>> The merging can happen inside the guest, depending on your benchmark
>> application and the guest kernel's I/O stack.  It also happens in
>> QEMU's virtio-blk emulation.
>> 
>> The most recent versions of QEMU merge both read and write requests.
>> Older versions only merged write requests.
>> 
>> It would be more intuitive for request merging to happen after QEMU
>> I/O throttling checks.  Currently QEMU's I/O queue plug/unplug isn't
>> advanced enough to do the request merging, so it's done earlier in
>> the virtio-blk emulation code.

Alternatively we could keep the original number of requests and pass it
to throttle_account(), but I'm not sure if it's a good idea.

> I wouldn't consider this behavior bad. Instead of virtio-blk merging
> the request the guest could have issued big IOPS right from the
> beginning. If you are concerned that big I/O is harming your storage,
> you can define a maximum iops_size for throttling or limit the maximum
> bandwidth.

That's right. The way throttling.iops-size works is that I/O requests
larger than this are accounted as if they were split into smaller
operations. So, if iops-size is 32KB, a 128KB request will be counted as
4 for the purpose of limiting the number of IOPS.

Berto



reply via email to

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