From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGHuV-0006xZ-Ag for qemu-devel@nongnu.org; Tue, 27 Jan 2015 20:59:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGHuP-0005zm-HR for qemu-devel@nongnu.org; Tue, 27 Jan 2015 20:59:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGHuP-0005zi-9M for qemu-devel@nongnu.org; Tue, 27 Jan 2015 20:59:09 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0S1x8TO017874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 27 Jan 2015 20:59:08 -0500 Date: Wed, 28 Jan 2015 09:59:06 +0800 From: Fam Zheng Message-ID: <20150128015906.GD8368@ad.nay.redhat.com> References: <1421397983-28065-1-git-send-email-famz@redhat.com> <1421397983-28065-6-git-send-email-famz@redhat.com> <54C6A773.1090903@redhat.com> <20150127030331.GB7715@fam-t430.nay.redhat.com> <54C7B970.5080002@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54C7B970.5080002@redhat.com> Subject: Re: [Qemu-devel] [PATCH v5 5/5] qemu-iotests: Add 093 for IO throttling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi On Tue, 01/27 11:14, Max Reitz wrote: > On 2015-01-26 at 22:03, Fam Zheng wrote: > >On Mon, 01/26 15:45, Max Reitz wrote: > >>On 2015-01-16 at 03:46, Fam Zheng wrote: > >>>This case utilizes qemu-io command "aio_{read,write} -q" to verify the > >>>effectiveness of IO throttling options. > >>> > >>>It's implemented by driving the vm timer from qtest protocol, so the > >>>throttling timers are signaled with determinied time duration. Then we > >>>verify the completed IO requests are within 10% error of bps and iops > >>>limits. > >>> > >>>"null" protocol is used as the disk backend so that no actual disk IO is > >>>performed on host, this will make the blockstats much more > >>>deterministic. Both "null-aio" and "null-co" are covered, which is also > >>>a simple cross validation test for the driver code. > >>> > >>>Signed-off-by: Fam Zheng > >>>--- > >>> tests/qemu-iotests/093 | 103 +++++++++++++++++++++++++++++++++++++++++++++ > >>> tests/qemu-iotests/093.out | 5 +++ > >>> tests/qemu-iotests/group | 1 + > >>> 3 files changed, 109 insertions(+) > >>> create mode 100755 tests/qemu-iotests/093 > >>> create mode 100644 tests/qemu-iotests/093.out > >>NACK. This literally kills my laptop (I can recover when running this test > >>in tmpfs (for some reason inexplicable to me, since this uses the null block > >>drivers...), but I cannot when running it on my HDD). > >> > >>Would it be possible to use larger requests and smaller iops? (Or just the > >>same request size but smaller bps as well) > >Is it because of CPU or memory? 1000 requests for both read and write seem to > >be overkilling since we are measuring 1000 bps and 10 iops, please try if > >reducing to 100 requests works for you. > > Probably memory, since I seem to recall you having the same model as me, but > I can imagine you having more RAM... > > 100 requests do not work with 128,000 bps/64 iops/10 seconds (because that'd > be more than 1 MB of data, whereas 100 requests of 4 kB are of course only > 400 kB), but the following constellations work: Oops, I changed bps and iops limits in v5 but was talking about 1000/10 here. We can still lower the limits though. I'll send a v6 for you to try soon. Fam