[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