qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 5/5] qemu-iotests: Add 093 for IO throttling


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v5 5/5] qemu-iotests: Add 093 for IO throttling
Date: Wed, 28 Jan 2015 12:11:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Fam Zheng <address@hidden> writes:

> 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 <address@hidden>
>> >>>---
>> >>>  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.

In general, please be mindful of test sizes, especially for tests in the
quick group.

Large sizes do cover more ground than small ones, but returns on
investment are diminishing sharply beyond a certain point.

We want everyone to run the quick tests all the time.  They better be
quick then, even on a somewhat underpowered laptop.  Not all
contributors work on company-sponsored, beefy new hardware.

When we have reason to believe that a big size is worthwhile to test, by
all means let's test it.  But let's test it outside the quick group.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]