[BENCHMARK] 2.5.59-mm6 with contest

[BENCHMARK] 2.5.59-mm6 with contest

[Con Kolivas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here are contest (http://contest.kolivas.net) benchmark results with the osdl 
hardware (http://www.osdl.org) for 2.5.59-mm6 (reconfigured hardware again to 
get most useful results with contest). These results have been checked for 
accuracy, repeatability and asterisks have been placed next to statistically 
significant differences.

I do believe these show that sequential reads are indeed scheduled before 
writes with this kernel.  The question is, how long should they be scheduled 
for?

no_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       79      94.9    0       0.0     1.00
2.5.59-mm6      1       78      96.2    0       0.0     1.00
cacherun:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       76      98.7    0       0.0     0.96
2.5.59-mm6      1       76      97.4    0       0.0     0.97
process_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       92      81.5    28      16.3    1.16
2.5.59-mm6      1       92      81.5    25      15.2    1.18
ctar_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       98      80.6    2       5.1     1.24*
2.5.59-mm6      3       112     70.5    2       4.5     1.44*
xtar_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       101     75.2    1       4.0     1.28*
2.5.59-mm6      3       115     66.1    1       4.3     1.47*
io_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       153     50.3    8       13.7    1.94*
2.5.59-mm6      3       106     70.8    4       9.4     1.36*
read_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       102     76.5    5       4.9     1.29*
2.5.59-mm6      3       733     10.8    56      6.3     9.40*
list_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       95      80.0    0       6.3     1.20*
2.5.59-mm6      3       97      79.4    0       6.2     1.24*
mem_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       97      80.4    56      2.1     1.23
2.5.59-mm6      3       94      83.0    50      2.1     1.21
dbench_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       126     60.3    3       22.2    1.59
2.5.59-mm6      3       122     61.5    3       25.4    1.56
io_other:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       89      84.3    2       5.5     1.13
2.5.59-mm6      2       90      83.3    2       6.7     1.15

io_load result is excellent showing the continuous write is delaying kernel 
compilation by much less. read_load tells the rest of the story though. 
read_load repeatedly reads a 256Mb file (the size of physical ram in the test 
machine)

Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE+Og8RF6dfvkL3i1gRAvLaAJ96HIePSeQ3TasNr8o19fzJGOyUUwCfTM4w
UKY8C9r2/2F5e4rrv9yOx7g=
=y8wz
-----END PGP SIGNATURE-----

Re: [BENCHMARK] 2.5.59-mm6 with contest

[Andrew Morton]

Con Kolivas <conman@kolivas.net> wrote:
>
> I do believe these show that sequential reads are indeed scheduled before 
> writes with this kernel.  The question is, how long should they be scheduled 
> for?

No, Nick has some logic in there which remembers the last-submitted sector
and treats that as an insertion candidate as well.  That's unrelated to
the anticipatory code.

Which is all fine, but it needs some taming to prevent the obvious starvation
which can happen.

I'm going to nobble that for now.  There have been enormous gyrations in the
behaviour of the IO scheduler in recent months and I wish to get it settled
down to good all-round behaviour _without_ the anticipatory scheduler in
place.  Because there are fairly hairy issues surrounding the anticipatory
scheduler and device drivers - anticipatory scheduling may not get there.

I have spent some time this week tuning up and fixing the non-anticipatory
I/O scheduler and I'd like to stabilise that code for a while, to provide a
decent baseline against which to continue the anticipatory development.

In fact, the tuned-up scheduler performs respectably against the anticipatory
code.  Which isn't theoretically correct, and indicates that the anticipatory
code can be optimised further.