From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZQ8SK-00066s-FW for qemu-devel@nongnu.org; Fri, 14 Aug 2015 02:27:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZQ8SH-0004YW-14 for qemu-devel@nongnu.org; Fri, 14 Aug 2015 02:27:08 -0400 Received: from smtp3.mundo-r.com ([212.51.32.191]:49246 helo=smtp4.mundo-r.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZQ8SG-0004OF-Qu for qemu-devel@nongnu.org; Fri, 14 Aug 2015 02:27:04 -0400 From: Alberto Garcia In-Reply-To: <9E0FAA0A-D30A-4AA9-8EB6-EAD3FF3954FC@kamp.de> References: <20150810001525.6231.66973.malonedeb@gac.canonical.com> <20150810095900.GB31433@stefanha-thinkpad.redhat.com> <9E0FAA0A-D30A-4AA9-8EB6-EAD3FF3954FC@kamp.de> Date: Fri, 14 Aug 2015 08:26:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Peter Lieven , Stefan Hajnoczi Cc: Kevin Wolf , Bug 1483070 <1483070@bugs.launchpad.net>, qemu-devel@nongnu.org On Fri 14 Aug 2015 01:34:50 AM CEST, Peter Lieven 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