mistranslation: 0.909 register: 0.899 user-level: 0.895 permissions: 0.884 risc-v: 0.870 assembly: 0.865 TCG: 0.862 arm: 0.861 performance: 0.849 VMM: 0.838 hypervisor: 0.836 vnc: 0.829 peripherals: 0.827 graphic: 0.820 PID: 0.819 kernel: 0.807 debug: 0.801 device: 0.782 KVM: 0.781 semantic: 0.761 files: 0.760 virtual: 0.748 boot: 0.745 ppc: 0.724 architecture: 0.720 x86: 0.607 network: 0.592 socket: 0.569 i386: 0.449 -------------------- virtual: 0.968 TCG: 0.926 performance: 0.919 register: 0.889 hypervisor: 0.888 KVM: 0.854 debug: 0.643 risc-v: 0.625 device: 0.272 PID: 0.265 boot: 0.246 kernel: 0.214 socket: 0.194 vnc: 0.106 semantic: 0.095 files: 0.082 VMM: 0.062 x86: 0.040 architecture: 0.032 permissions: 0.026 assembly: 0.013 user-level: 0.011 peripherals: 0.010 network: 0.009 i386: 0.006 graphic: 0.004 ppc: 0.003 mistranslation: 0.002 arm: 0.001 VIRTIO Sequential Write IOPS limits not working Root Problem: IOPS limit does not work for VIRTIO devices if the disk workload is a sequential write. To confirm: IDE disk devices - the IOPS limit works fine. Disk transfer speed limit works fine. VIRTIO disk devices - the IOPS limit works fine for random IO (write/read) and sequential read, but not for sequential write. Disk transfer speed limits work fine. Tested on Windows 7,10 and 2k12 (Fedora drivers used and here is the twist): virtio-win-0.1.96 (stable) or older won't limit write IO if workload is sequential. virtio-win-0.1.105 (latest) or newer will limit but I have had two test machines crash when under high workload using IOPS limit. For Linux: The issue is also apparent, tested on Ubuntu 14.04 On the hypervisor (using KVM) machine I have tried with Qemu 2.1.2 (3.16.0-4-amd64 - Debian 8) and Qemu 2.3.0 (3.19.8-1-pve - Proxmox 3.4 and 4) using multiple machines but all are 64bit intel. Even though the latest VIRTIO guest drivers fix the problem, the guest drivers shouldn't be able to ignore the limits the host puts in place or am I missing something?? On Mon, Aug 10, 2015 at 12:15:25AM -0000, James Watson wrote: > IOPS limit does not work for VIRTIO devices if the disk workload is a sequential write. > > To confirm: > IDE disk devices - the IOPS limit works fine. Disk transfer speed limit works fine. > VIRTIO disk devices - the IOPS limit works fine for random IO (write/read) and sequential read, but not for sequential write. Disk transfer speed limits work fine. > > Tested on Windows 7,10 and 2k12 (Fedora drivers used and here is the twist): > virtio-win-0.1.96 (stable) or older won't limit write IO if workload is sequential. > virtio-win-0.1.105 (latest) or newer will limit but I have had two test machines crash when under high workload using IOPS limit. > > For Linux: > The issue is also apparent, tested on Ubuntu 14.04 > > On the hypervisor (using KVM) machine I have tried with Qemu 2.1.2 > (3.16.0-4-amd64 - Debian 8) and Qemu 2.3.0 (3.19.8-1-pve - Proxmox 3.4 > and 4) using multiple machines but all are 64bit intel. > > Even though the latest VIRTIO guest drivers fix the problem, the guest > drivers shouldn't be able to ignore the limits the host puts in place or > am I missing something?? 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. I've CCed Kevin Wolf, Alberto Garcia, and Peter Lieven who may have more thoughts on this. Am 10.08.2015 um 11:59 schrieb Stefan Hajnoczi