|| ||Con Kolivas <email@example.com>|
|| ||[BENCHMARK] Greater resolution mem_load from contest|
|| ||Sat, 21 Sep 2002 00:12:49 +1000|
|| ||Andrew Morton <firstname.lastname@example.org>|
Here are some results you may find informative.
I adjusted the mem_load module of contest (http://contest.kolivas.net) to vary
the memory load from 10 to 110% in increments of 10% and performed the test on
the following kernels.
What I found is that performance regardless of the kernel was constant (for that
kernel) up to 70% (presumably the critical number for my 256Mb machine).
What happened beyond this point, however, was quite different between kernels.
Here are the results:
Kernel: 2.4.19 rmap14b 2.5.36 2.5.36-mm1
60 76.34 76.98 66.62 69.12
70 76.22 77.14 67.21 67.28
80 79.20 80.14 68.24 70.29
90 82.59 115.51 148.63 92.96
100 84.21 108.61 107.54 95.50
110 92.49 114.51 132.45 95.32
As you can see, in absoute performance the 2.5 kernels at low mem loads are better.
rmap14b (2.4.19-rmap14b) performance is identical to vanilla till 80%.
Beyond this point it starts to deteriorate rapidly.
2.5.36 exhibits this same behaviour (presumably for the same reason?).
Note the dip at exactly 100% and the peak either side of it?
-mm1 seems to do better than vanilla 2.5.36
Overall, vanilla 2.4.19 seems to respond more graded.
A quick reminder what these numbers are;
the data value is the time taken to compile a kernel, and the mem% is a
background memory load that continually asks for x% of the memory.
I'd like to include the ability to test this into a newer version of contest;
however the critical point when the results start to deteriorate, and the
absolute resolution required to show the difference will be dependent on the
test machine's memory. I haven't resolved the best way around this.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/