On Fri 14 Aug 2015 01:34:50 AM CEST, Peter Lieven <p...@kamp.de> 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
