Re: [RFC] IO scheduler based io controller (V5)
From: Vladislav Bolkhovitin
Date: Mon Jun 29 2009 - 12:04:50 EST
Hi,
Vivek Goyal, on 06/20/2009 12:37 AM wrote:
Hi All,
Here is the V5 of the IO controller patches generated on top of 2.6.30.
Previous versions of the patches was posted here.
(V1) http://lkml.org/lkml/2009/3/11/486
(V2) http://lkml.org/lkml/2009/5/5/275
(V3) http://lkml.org/lkml/2009/5/26/472
(V4) http://lkml.org/lkml/2009/6/8/580
This patchset is still work in progress but I want to keep on getting the
snapshot of my tree out at regular intervals to get the feedback hence V5.
[..]
Testing
=======
I have been able to do only very basic testing of reads and writes.
Test1 (Fairness for synchronous reads)
======================================
- Two dd in two cgroups with cgrop weights 1000 and 500. Ran two "dd" in those
cgroups (With CFQ scheduler and /sys/block/<device>/queue/fairness = 1)
dd if=/mnt/$BLOCKDEV/zerofile1 of=/dev/null &
dd if=/mnt/$BLOCKDEV/zerofile2 of=/dev/null &
234179072 bytes (234 MB) copied, 3.9065 s, 59.9 MB/s
234179072 bytes (234 MB) copied, 5.19232 s, 45.1 MB/s
Sorry, but the above isn't a correct way to test proportional fairness
for synchronous reads. You need throughput only when *both* dd's
running, don't you?
Considering both transfers started simultaneously (which isn't obvious
too) in the way you test the throughput value only for the first
finished dd is correct, because after it finished, the second dd started
transferring data *alone*, hence the result throughput value for it got
partially for simultaneous, partially for alone reads, i.e. screwed.
I'd suggest you instead test as 2 runs of:
1. while true; do dd if=/mnt/$BLOCKDEV/zerofile1 of=/dev/null; done
dd if=/mnt/$BLOCKDEV/zerofile2 of=/dev/null
2. while true; do dd if=/mnt/$BLOCKDEV/zerofile2 of=/dev/null; done
dd if=/mnt/$BLOCKDEV/zerofile1 of=/dev/null
and take results from the standalone dd's.
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/