Re: RFC on io-stalls patch

[Chris Mason <mason@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 3712 bytes --]

On Tue, 2003-07-15 at 05:17, Jens Axboe wrote:

> > BTW, the contest run times vary pretty wildy.  My 3 compiles with
> > io_load running on 2.4.21 were 603s, 443s and 515s.  This doesn't make
> > the average of the 3 numbers invalid, but we need a more stable metric.
> 
> Mine are pretty consistent [1], I'd suspect that it isn't contest but your
> drive tcq skewing things. But it would be nice to test with other things
> as well, I just used contest because it was at hand.

I hacked up my random io generator a bit, combined with tiobench it gets
pretty consistent numbers.  rio is attached, it does lots of different
things but the basic idea is to create a sparse file and then do io of
random sizes into random places in the file.

So, random writes with a large max record size can starve readers pretty
well.  I've been running it like so:

#!/bin/sh
#
# rio sparse file size of 2G, writes only, max record size 1MB
#
rio -s 2G -W -m 1m &
kid=$!
sleep 1
tiobench.pl --threads 8
kill $kid
wait

tiobench is nice because it also gives latency numbers, I'm playing a
bit to see how the number of tiobench threads changes things, but the
contest output is much easier to compare.  After a little formatting:

Sequential Reads
            File  Blk   Num                   Avg      Maximum      Lat%     Lat%    CPU
Identifier  Size  Size  Thr   Rate  (CPU%)  Latency    Latency      >2s      >10s    Eff
------------ ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----
2.4.22-pre5 1792  4096    8    6.92 2.998%     4.363     9666.86   0.02245  0.00000   231
2.4.21      1792  4096    8    8.40 3.275%     3.052     3249.79   0.00131  0.00000   256

Random Reads
            File  Blk   Num                   Avg      Maximum      Lat%     Lat%    CPU
Identifier  Size  Size  Thr   Rate  (CPU%)  Latency    Latency      >2s      >10s    Eff
------------ ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----
2.4.22-pre5 1792  4096    8    1.41 0.540%    20.932      604.13   0.00000  0.00000   260
2.4.21      1792  4096    8    0.65 0.540%    41.458     2689.96   0.05000  0.00000   120

Sequential Writes
            File  Blk   Num                   Avg      Maximum      Lat%     Lat%    CPU
Identifier  Size  Size  Thr   Rate  (CPU%)  Latency    Latency      >2s      >10s    Eff
------------ ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----
2.4.22-pre5 1792  4096    8   13.77 8.793%     1.550     3416.72   0.00567  0.00000   157
2.4.21      1792  4096    8   15.38 8.847%     1.169    47134.93   0.00719  0.00305   174

Random Writes
            File  Blk   Num                   Avg      Maximum      Lat%     Lat%    CPU
Identifier  Size  Size  Thr   Rate  (CPU%)  Latency    Latency      >2s      >10s    Eff
------------ ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----
2.4.22-pre5 1792  4096    8    0.68 1.470%     0.027       12.91   0.00000  0.00000    46
2.4.21      1792  4096    8    0.67 0.598%     0.043       67.21   0.00000  0.00000   112

rio output:
2.4.22-pre5 total io 2683.087 MB, 428.000 seconds 6.269 MB/s
2.4.21      total io 3231.576 MB, 381.000 seconds 8.482 MB/s
2.4.22-pre5 writes: 2683.087 MB, 6.269 MB/s
2.4.21      writes: 3231.576 MB, 8.482 MB/s

Without breaking tiobench apart to skip the write phase it is hard to
tell where the rio throughput loss is.  My guess is that most of it was
lost during the sequential write tiobench phase.

Since jens is getting consistent contest numbers, this isn't meant to
replace it.  Just another data point worth looking at.  Jens if you want
to send me your current patch I can give it a quick spin here.

-chris


[-- Attachment #2: rio.c.gz --]
[-- Type: application/x-gzip, Size: 3177 bytes --]