rmap15, rmap14c and rc1aa1 with contest

BENCHMARK Nero 3 participants 5 messages Nov 24, 2002

Share & tools

Nero

author

2002-11-24 13:10 UTC #0 lore raw

noload:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       84.6    95      0       0       1.00
2.4.19-rmap14c [1]      84.2    96      0       0       1.00
2.4.20-rc1aa1 [2]       41.0    49      0       0       inf

process_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       140.8   55      133     45      1.66
2.4.19-rmap14c [1]      139.4   56      126     45      1.65
2.4.20-rc1aa1 [2]       133.9   14      211     84      inf

io_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       164.8   51      33      19      1.95
2.4.19-rmap14c [1]      160.1   53      33      21      1.90
2.4.20-rc1aa1 [1]       166.2   49      44      23      inf

read_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       0.0     0       0       7       0.00
2.4.19-rmap14c [1]      121.0   72      20      7       1.44
2.4.20-rc1aa1 [1]       111.2   79      34      14      inf

rmap15 OOM'd the cc1 process twice and fscked this run up.

list_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       99.2    84      0       7       1.17
2.4.19-rmap14c [1]      100.7   83      0       7       1.20
2.4.20-rc1aa1 [1]       96.7    85      0       8       inf

mem_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       111.2   80      96      8       1.31
2.4.19-rmap14c [1]      106.1   82      96      9       1.26
2.4.20-rc1aa1 [1]       126.3   66      77      3       inf

Nero

author

2002-11-24 13:19 UTC #1 lore raw

Quoted 5 lines · Nero

noload:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       84.6    95      0       0       1.00
2.4.19-rmap14c [1]      84.2    96      0       0       1.00
2.4.20-rc1aa1 [2]       41.0    49      0       0       inf

The time for rc1aa1 here is obviously wrong - this is a bug in contest, according to Dr. Kolivas :-)

Quoted 33 lines

process_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       140.8   55      133     45      1.66
2.4.19-rmap14c [1]      139.4   56      126     45      1.65
2.4.20-rc1aa1 [2]       133.9   14      211     84      inf

io_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       164.8   51      33      19      1.95
2.4.19-rmap14c [1]      160.1   53      33      21      1.90
2.4.20-rc1aa1 [1]       166.2   49      44      23      inf

read_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       0.0     0       0       7       0.00
2.4.19-rmap14c [1]      121.0   72      20      7       1.44
2.4.20-rc1aa1 [1]       111.2   79      34      14      inf

rmap15 OOM'd the cc1 process twice and fscked this run up.

list_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       99.2    84      0       7       1.17
2.4.19-rmap14c [1]      100.7   83      0       7       1.20
2.4.20-rc1aa1 [1]       96.7    85      0       8       inf

mem_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       111.2   80      96      8       1.31
2.4.19-rmap14c [1]      106.1   82      96      9       1.26
2.4.20-rc1aa1 [1]       126.3   66      77      3       inf

Con Kolivas

2002-11-24 13:23 UTC #2 lore raw

In reply to Nero

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

Thanks for this interesting comparison

Quoted 5 lines

noload:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       84.6    95      0       0       1.00
2.4.19-rmap14c [1]      84.2    96      0       0       1.00
2.4.20-rc1aa1 [2]       41.0    49      0       0       inf

Clearly my braindead parser failed here. The time of aa1 should probably be 82 seconds (41.0 x 2) Can you check the full log of 2.4.20-rc1aa1.log ? It has raw results.

Quoted 5 lines

process_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       140.8   55      133     45      1.66
2.4.19-rmap14c [1]      139.4   56      126     45      1.65
2.4.20-rc1aa1 [2]       133.9   14      211     84      inf

If the error continued here (2 runs of process_load) then the time of aa1 should be 133.9 x 2. Can you check the full log of 2.4.20-rc1aa1.log here too?

Quoted 20 lines

io_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       164.8   51      33      19      1.95
2.4.19-rmap14c [1]      160.1   53      33      21      1.90
2.4.20-rc1aa1 [1]       166.2   49      44      23      inf

read_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       0.0     0       0       7       0.00
2.4.19-rmap14c [1]      121.0   72      20      7       1.44
2.4.20-rc1aa1 [1]       111.2   79      34      14      inf

rmap15 OOM'd the cc1 process twice and fscked this run up.

list_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       99.2    84      0       7       1.17
2.4.19-rmap14c [1]      100.7   83      0       7       1.20
2.4.20-rc1aa1 [1]       96.7    85      0       8       inf

Quoted 5 lines

mem_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       111.2   80      96      8       1.31
2.4.19-rmap14c [1]      106.1   82      96      9       1.26
2.4.20-rc1aa1 [1]       126.3   66      77      3       inf

With only one run these numbers appear not to be greatly statistically significant, except for the mem_load results.

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

iD8DBQE94NTSF6dfvkL3i1gRAkwXAJ9YJmnxvxdiYyESNYLeQa9sbwR+2wCcCZal bFKWReK3EP8oayP/GwiIK7c=
=gYaS
-----END PGP SIGNATURE-----

Nero

author

2002-11-24 13:27 UTC #3 lore raw

In reply to Nero

Quoted 13 lines · Con Kolivas

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

Thanks for this interesting comparison

Quoted 5 lines

noload:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       84.6    95      0       0       1.00
2.4.19-rmap14c [1]      84.2    96      0       0       1.00
2.4.20-rc1aa1 [2]       41.0    49      0       0       inf

Quoted 4 lines

Clearly my braindead parser failed here. The time of aa1 should probably be 82 seconds (41.0 x 2) Can you check the full log of 2.4.20-rc1aa1.log ? It has raw results.

Yep.
noload Time: 81.95 CPU: 98% LoadRuns: 0 LoadCPU%: 0

Quoted 11 lines

Quoted 6 lines
process_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       140.8   55      133     45      1.66
2.4.19-rmap14c [1]      139.4   56      126     45      1.65
2.4.20-rc1aa1 [2]       133.9   14      211     84      inf
If the error continued here (2 runs of process_load) then the time of aa1 should be 133.9 x 2. Can you check the full log of 2.4.20-rc1aa1.log here too?

process_load Time: 267.85 CPU: 29% LoadRuns: 422 LoadCPU%: 70%

Quoted 42 lines

Quoted 22 lines
io_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       164.8   51      33      19      1.95
2.4.19-rmap14c [1]      160.1   53      33      21      1.90
2.4.20-rc1aa1 [1]       166.2   49      44      23      inf
read_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       0.0     0       0       7       0.00
2.4.19-rmap14c [1]      121.0   72      20      7       1.44
2.4.20-rc1aa1 [1]       111.2   79      34      14      inf
rmap15 OOM'd the cc1 process twice and fscked this run up.
list_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       99.2    84      0       7       1.17
2.4.19-rmap14c [1]      100.7   83      0       7       1.20
2.4.20-rc1aa1 [1]       96.7    85      0       8       inf
Quoted 5 lines
mem_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       111.2   80      96      8       1.31
2.4.19-rmap14c [1]      106.1   82      96      9       1.26
2.4.20-rc1aa1 [1]       126.3   66      77      3       inf
With only one run these numbers appear not to be greatly statistically significant, except for the mem_load results.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE94NTSF6dfvkL3i1gRAkwXAJ9YJmnxvxdiYyESNYLeQa9sbwR+2wCcCZal bFKWReK3EP8oayP/GwiIK7c=
=gYaS
-----END PGP SIGNATURE-----

Rik van Riel

2002-11-24 17:32 UTC #4 lore raw

In reply to Nero

Quoted 7 lines · Nero

read_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19-rmap15 [1]       0.0     0       0       7       0.00
2.4.19-rmap14c [1]      121.0   72      20      7       1.44
2.4.20-rc1aa1 [1]       111.2   79      34      14      inf

rmap15 OOM'd the cc1 process twice and fscked this run up.

Known bug, should be fixed with the 2.4.19-rmap15-splitactive patch I posted on friday:

	http://surriel.com/patches/2.4/2.4.19-rmap15-splitactive

cheers,

Rik

Signature · 3 lines

Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"[email protected]">[email protected]</a>