On Wed, 14 Nov 2007 14:24:03 -0500
"Alan D. Brunelle" <Alan.Brunelle@hp.com> wrote:
quoted text
> >   
> 
> The test works like this:
> 
>    1. I ensure that the device under test (DUT) is set to run the CFQ
>       scheduler.
>          1. It is a Fibre Channel 72GiB disk
>          2. Single partition...
>    2. Put an Ext3 FS on the partition (mkfs.ext3 -b 4096)
>    3. Mount the device, and then:
>          1. Put an 8GiB file on the new FS
>          2. Put 3 copies of a Linux tree (w/ objs & kernel & such)
> onto the FS in separate directories
>                1. Note: I'm going to do runs with 6 copies to each
>                   directory tree to get to about 4.2GiB per directory
> tree 4. Then, for each of the tests:
>          1. Remount the device (purge page cache by umount & then
> mount) 2. Start up a copy of 1 kernel tree to another tree (you hadn't
>             specified if the copy in the background should be to a new
>             area or not, so I'm just re-using the same area so we
> don't have to worry about removing the old). I keep doing the copy
>             as long as the tests are going
>          3. Perform the test (10 times)
> 
> The tests are:
> 
>     * Linear read of a large file (8GiB)
>     * Tree read (foreach file in the tree, dd it to /dev/null)
>     * Overwrite of that large file: was doing 256KiB random&direct
>       read/writes, will go down to 4KiB read/writes as that is more
>       realistic I'd guess
> 

ok so the obvious meta-question is this: what does it mean that your
test takes longer or shorter. I can see IO "capacity" (trying to avoid
the use bandwidth here) moves from the foreground test to the
background test (and/or other way around)... but if that was starved
previously... it could or could not be the right result.
What do you think the measure of "it's at least not worse" is? Is there
any way to get to that concept? (and then looking at if that got met is
the second step ;( )

-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/