public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [BENCHMARK] 2.5.59{-mm2} with contest
@ 2003-01-18 13:50 Con Kolivas
  2003-01-18 21:47 ` Andrew Morton
  0 siblings, 1 reply; 2+ messages in thread
From: Con Kolivas @ 2003-01-18 13:50 UTC (permalink / raw)
  To: linux kernel mailing list; +Cc: Andrew Morton

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

Contest (http://contest.kolivas.net) benchmarks with the osdl 
(http://www.osdl.org) hardware on 2.5.59 and mm2:

no_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.58          3       74      95.9    0       0.0     1.00
2.5.58-mm1      3       74      94.6    0       0.0     1.00
2.5.59          3       74      94.6    0       0.0     1.00
2.5.59-mm2      4       74      95.9    0       0.0     1.00
cacherun:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.58          3       73      97.3    0       0.0     0.99
2.5.58-mm1      3       72      97.2    0       0.0     0.97
2.5.59          3       72      97.2    0       0.0     0.97
2.5.59-mm2      3       72      98.6    0       0.0     0.97
process_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.58          3       89      79.8    28      16.9    1.20
2.5.58-mm1      3       87      80.5    26      16.1    1.18
2.5.59          3       88      80.7    27      15.9    1.19
2.5.59-mm2      3       89      79.8    29      18.0    1.20
ctar_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.58          3       107     82.2    2       6.5     1.45
2.5.58-mm1      3       102     80.4    2       7.8     1.38
2.5.59          3       106     81.1    2       7.5     1.43
2.5.59-mm2      3       97      77.3    1       4.1     1.31
xtar_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.58          3       119     78.2    1       5.9     1.61
2.5.58-mm1      3       107     79.4    1       5.6     1.45
2.5.59          3       118     78.0    1       5.9     1.59
2.5.59-mm2      3       99      73.7    1       6.1     1.34
io_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.58          3       136     58.8    6       12.4    1.84
2.5.58-mm1      3       138     55.8    7       13.0    1.86
2.5.59          4       113     68.1    4       9.7     1.53
2.5.59-mm2      3       563     12.8    38      17.4    7.61
read_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.58          3       96      81.2    6       6.2     1.30
2.5.58-mm1      3       97      79.4    6       6.2     1.31
2.5.59          3       96      79.2    6       6.2     1.30
2.5.59-mm2      3       137     54.7    9       6.6     1.85
list_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.58          3       87      83.9    0       8.0     1.18
2.5.58-mm1      3       87      83.9    0       8.0     1.18
2.5.59          3       87      83.9    0       8.0     1.18
2.5.59-mm2      2       87      83.9    0       8.0     1.18
mem_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.58          3       97      77.3    46      1.0     1.31
2.5.58-mm1      3       100     73.0    50      1.0     1.35
2.5.59          3       99      74.7    48      1.0     1.34
2.5.59-mm2      3       95      76.8    48      1.0     1.28
dbench_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.58          3       120     63.3    3       21.7    1.62
2.5.58-mm1      3       122     60.7    3       23.8    1.65
2.5.59          3       108     69.4    2       15.7    1.46
2.5.59-mm2      3       120     60.0    3       26.7    1.62

HELLO! Something going on here. Went back and repeated results and looked 
carefully - can't see any funny business going on at my end. Modest changes 
from 2.5.58-59 and big changes with -mm2.

Full details and archived results available at:
http://www.osdl.org/projects/ctdevel/results/
Only results with current version of contest and hardware setup are kept 
there.

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

iD8DBQE+KVu7F6dfvkL3i1gRAkiXAJsHQYc1QWioZRGiap9+6STXcywVtwCdFmOW
oZ/gfmCZTA4C6WZPGYcPToQ=
=vV66
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [BENCHMARK] 2.5.59{-mm2} with contest
  2003-01-18 13:50 [BENCHMARK] 2.5.59{-mm2} with contest Con Kolivas
@ 2003-01-18 21:47 ` Andrew Morton
  0 siblings, 0 replies; 2+ messages in thread
From: Andrew Morton @ 2003-01-18 21:47 UTC (permalink / raw)
  To: Con Kolivas; +Cc: linux-kernel, Nick Piggin

Con Kolivas <conman@kolivas.net> wrote:
>
> io_load:
> Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
> 2.5.58          3       136     58.8    6       12.4    1.84
> 2.5.58-mm1      3       138     55.8    7       13.0    1.86
> 2.5.59          4       113     68.1    4       9.7     1.53
> 2.5.59-mm2      3       563     12.8    38      17.4    7.61

I don't see such gross variations here, and there's nothing between -mm1 and
-mm2 which could cause this.  (BTW: what idiot broke diffstat as distributed
in rh8.0?  It fails to understand interdiff output, which is quite
legitimately formatted).

However there are some interesting snippets.  Elapsed time for io_load:

2.5.59: 					182,183,180
2.5.59 + deadline-np-42:			198,114,106,112,183,140
2.5.59 + deadline-np-42 + deadline-np-43:	224,224
2.5.59-mm2:					212,239

So it looks like deadline-np-42.patch lessens starvation of reads by writes,
and deadline-np-43.patch considerably worsens it.

But this is all just fiddling around.  Nick is working on an implementation
of anticipatory scheduling, which is a whole new ball game.  The pressure is
on ;)



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-01-18 21:36 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-18 13:50 [BENCHMARK] 2.5.59{-mm2} with contest Con Kolivas
2003-01-18 21:47 ` Andrew Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox