From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZQ20d-0000VI-Bz for qemu-devel@nongnu.org; Thu, 13 Aug 2015 19:34:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZQ20Y-0005lM-9m for qemu-devel@nongnu.org; Thu, 13 Aug 2015 19:34:07 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:54872 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZQ20X-0005kM-VS for qemu-devel@nongnu.org; Thu, 13 Aug 2015 19:34:02 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Peter Lieven In-Reply-To: <20150810095900.GB31433@stefanha-thinkpad.redhat.com> Date: Fri, 14 Aug 2015 01:34:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9E0FAA0A-D30A-4AA9-8EB6-EAD3FF3954FC@kamp.de> References: <20150810001525.6231.66973.malonedeb@gac.canonical.com> <20150810095900.GB31433@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] [Bug 1483070] [NEW] VIRTIO Sequential Write IOPS limits not working List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Bug 1483070 <1483070@bugs.launchpad.net>, berto@igalia.com, qemu-devel@nongnu.org Am 10.08.2015 um 11:59 schrieb Stefan Hajnoczi : > 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> For Linux: >> The issue is also apparent, tested on Ubuntu 14.04 >>=20 >> 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. >>=20 >> 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?? >=20 > This is probably due to I/O request merging: >=20 > 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. >=20 > 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. >=20 > The most recent versions of QEMU merge both read and write requests. > Older versions only merged write requests. >=20 > 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. >=20 > I've CCed Kevin Wolf, Alberto Garcia, and Peter Lieven who may have = more > thoughts on this. 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. Peter