UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
I performed the following tests running both 2.4.0-test12-pre7 and 2.2.18-pre26. All kernel builds were done in console mode (no X).
All numbers are seconds required to make bzImage. Times were obtained using the date command before and after make bzImage in a script. Each test was performed three times.
1 2 3 ave.
449 443 440 444 make bzImage for 2.4.0t12p7 running 2.2.18p26
460 458 454 457.3 make bzImage for 2.4.0t12p7 running 2.4.0t12p7
310 310 307 309 make bzImage for 2.2.18p26 running 2.2.18p26 318 319 317 318 make bzImage for 2.2.18p26 running 2.4.0t12p7
2.2.18p26 is shorthand for 2.2.18-pre26.
2.4.0t12p7 is shorthand for 2.4.0-test12-pre7.
2.2.18-pre26 was patched with reiserfs-3.5.28. 2.2.18-pre26 was compiled with gcc 2.91.66 (kgcc).
2.4.0-test12-pre7 was patched with reiserfs-3.6.22. 2.4.0-test12-pre7 was compiled with gcc 2.95.3.
The .config files were unchanged during the tests.
A make clean was performed before each test.
The test machine was not connected to a network during the tests. Test machine: single processor P-III (450 Mhz), 192MB, IDE disk (ST317221A).
Conclusion: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12 using ReiserFS. However, the margin of victory is small enough that a recount may be necessary.
It would be interesting to see results using ext2fs and results from SMP machines.
Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
| 2.2.18-pre26 was compiled with gcc 2.91.66 (kgcc). | 2.4.0-test12-pre7 was compiled with gcc 2.95.3.
That's your answer right there.
GCC 2.95.3 compiles much slower than kgcc.
Rerun the 2.4.0 with kgcc to be fair. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 1 line · Aaron Tiensivu
Rerun the 2.4.0 with kgcc to be fair. :)
Quoted 3 lines · John Fremlin
Two points: (1) gcc 2.95 makes slightly slower code than egcs-1.1 (according to benchmarks on gcc.gnu.org) so compile 2.4 kernel with egcs for a fairer comparison. (2) The new VM was a performance
Ok, several people have said that kgcc makes a slightly better (faster) kernel than gcc. Here are some more results.
1 2 3 ave.
453 456 455 454.7 make bzImage for 2.4.0t12p7 running 2.4.0t12p7kgcc
compare this to my previous test using test12-pre7 compiled with gcc:
460 458 454 457.3 make bzImage for 2.4.0t12p7 running 2.4.0t12p7gcc
2.4.0t12p7kgcc is shorthand for 2.4.0-test12-pre7k made with kgcc. 2.4.0t12p7gcc is shorthand for 2.4.0-test12-pre7 made with gcc.
kgcc does indeed make a slightly faster (0.5%) kernel, but I think we're getting into the pregnant or dimpled chad thing at this point.
To create a kgcc test12-pre7, I modified line 18 and 29 of the top level Makefile to be =kgcc. Of course, I then restored the Makefile to original, since I'm not testing how fast gcc vs kgcc compiles a bunch of code. I modified EXTRAVERSION to be -test12k so I could double check with uname -r to make sure I booted the correct kernel.
Kgcc made a somewhat larger kernel than gcc. The same .config file was used for both kernels.
829034 Dec 7 20:46 vmlinuz-2.4.0-test12-pre7
854863 Dec 11 14:12 vmlinuz-2.4.0-test12-pre7k
I have a SMP (dual P-III 733Mhz) machine at work, but it will be unavailable for testing for a few more days. I suspect that 2.4.0-test12 will do better than 2.2.18 with 2 CPUs. I'll know in a few days.
Building kernels is something we do so frequently and this test is so easy to reproduce is why I performed it in the first place. I think it may be as good a test of real performance as some of the more formal benchmarks. Comments anyone?
Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines · Steven Cole
I have a SMP (dual P-III 733Mhz) machine at work, but it will be unavailable for testing for a few more days. I suspect that 2.4.0-test12 will do better than 2.2.18 with 2 CPUs. I'll know in a few days.
Building kernels is something we do so frequently and this test is so easy to reproduce is why I performed it in the first place. I think it may be as good a test of real performance as some of the more formal benchmarks. Comments anyone?
I think it's better with -j. Do it with -jN where N is small enough to keep the box away from swap, and then repeat with N large enough to swap modestly (not too heavily or you're only testing disk MTBF:).
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · Mike Galbraith
Quoted 3 lines · Steven Cole
I have a SMP (dual P-III 733Mhz) machine at work, but it will be unavailable for testing for a few more days. I suspect that 2.4.0-test12 will do better than 2.2.18 with 2 CPUs. I'll know in a few days.
[snip]
Quoted 4 lines
I think it's better with -j. Do it with -jN where N is small enough to keep the box away from swap, and then repeat with N large enough to swap modestly (not too heavily or you're only testing disk MTBF:).
I've always used make -j2 bzImage for my two processor machine. I like being able to build kernels in a little over two minutes.
Simple question here, and risking displaying great ignorance:
Does it make sense to use make -jN where N is much greater than the number of CPUs?
Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 11 lines · Steven Cole
Quoted 4 lines · Mike Galbraith
Quoted 3 lines · Steven Cole
I have a SMP (dual P-III 733Mhz) machine at work, but it will be unavailable for testing for a few more days. I suspect that 2.4.0-test12 will do better than 2.2.18 with 2 CPUs. I'll know in a few days.
[snip]
Quoted 4 lines
I think it's better with -j. Do it with -jN where N is small enough to keep the box away from swap, and then repeat with N large enough to swap modestly (not too heavily or you're only testing disk MTBF:).
Quoted 6 lines
I've always used make -j2 bzImage for my two processor machine. I like being able to build kernels in a little over two minutes.
Simple question here, and risking displaying great ignorance:
Does it make sense to use make -jN where N is much greater than the number of CPUs?
If you're testing VM, definitely yes. Otherwise.. _not_ ;-)
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Steven Cole wrote:
[...]
Quoted 3 lines
Simple question here, and risking displaying great ignorance:
Does it make sense to use make -jN where N is much greater than the number of CPUs?
No, but it makes sense to have N at least one more than the number of cpus,
if you have the memory. This because your processes occationally will wait for disk io, and this time may then be utilized to run the "extra" task. But don't overdo it, as you get less disk cache this way. make -j3 seems to be fastest on my 2-cpu machine with 128M ram.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · Steven Cole
Building kernels is something we do so frequently and this test is so easy to reproduce is why I performed it in the first place. I think it may be as good a test of real performance as some of the more formal benchmarks. Comments anyone?
Just one comment. You cannot use a kernel build to measure other things than those subsystems which the kernel build excercises.
Things you could measure with a kernel build: scheduling (L2 cache efficiency), fork, readahead, cpu speed, framebuffer speed (in the make dep phase) and maybe hard disk speed.
Things you cannot measure with a kernel build: networking, swapping (unless you do a very big parallel build, and even then it's questionable), raw IO speed (the kernel build is latency sensitive, but doesn't need much throughput), ...
regards,
Rik
--
Hollywood goes for world dumbination,
Trailer at 11. http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 10 lines · Rik van Riel
Quoted 4 lines · Steven Cole
Building kernels is something we do so frequently and this test is so easy to reproduce is why I performed it in the first place. I think it may be as good a test of real performance as some of the more formal benchmarks. Comments anyone?
Just one comment. You cannot use a kernel build to measure other things than those subsystems which the kernel build excercises.
One comment back ;-)
Of course.
Quoted 3 lines
Things you could measure with a kernel build: scheduling (L2 cache efficiency), fork, readahead, cpu speed, framebuffer speed (in the make dep phase) and maybe hard disk speed.
Yes, among others. RealHardLife hard disk speed.. kinda sorta.
Quoted 4 lines
Things you cannot measure with a kernel build: networking, swapping (unless you do a very big parallel build, and even then it's questionable), raw IO speed (the kernel build is latency sensitive, but doesn't need much throughput), ...
I believe you are wrong wrt parallel kernel builds as swap test.. it's not questionable at all. :) Or, if it is, please explain why.
My view:
The kernel build is above and beyond all other considerations a CPU bound job which has a cachable component which is not negligable, and has an I/O component, but not a dominating one. That makes it an ideal generic test candidate for vm throughput.. in any box not blessed with unlimited I/O capability.
I think that a parallel kernel build is the perfect basic VM functional test _because_ of it's simple requirements. Limit the I/O to what your box can deliver (must know before testing), and it's fine.
I agree if you say that it's nothing beyond a basic functionality test.
I test this way because my box doesn't have the hardware to do serious I/O.. and neither do at least 99.9% of other boxen out there.
What else can you suggest to test basic VM throughput in an I/O starved environment? It has to be multi-task, and has to be CPU bound to be meaningful.
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/