Paolo Losi wrote:
> Hello everyone,
> these are the results obtained doing a full kernel compile after a
> reboot (make dep,make clean,make bzImage) on a P166MMX 64Mb RAM IDE DMA
> hd:
>
> linux 2.0.36pre1+Jumbo9
> 524.54user 47.96system 10:35.29elapsed 90%CPU (0avgtext+0avgdata
> 0maxresident)k 0inputs+0outputs (261405major+309077minor)pagefaults
> 0swaps
>
> linux 2.1.113
> 525.66user 39.60system 10:25.49elapsed 90%CPU (0avgtext+0avgdata
> 0maxresident)k 0inputs+0outputs (261096major+309034minor)pagefaults
> 0swaps
>
> can we say that, as far as the sub-systems involved are concerned, 2.1
> is 20% faster than 2.0?
In fact we can't say that. ;-)
There is a small methodological mistake in your test: basically, when
you do a "make dep; make clean", you are priming the dcache (in the
2.1.113 kernel run). The subsequent make bzImage will inevitably be
faster, compared to the 2.0.36 run.
Also, you must have noticed that kernel compilation is basically
CPU-bound. Like most applications, it is _not_ kernel bound. I am
looking for applications that are essentially kernel bound, but haven't
found a single one yet (I am not talking about synthetic test suites
such as LMBench).
In your example, overall gain in going from 2.0.x to 2.1.x is 1.5%. In
the same time span it took Linux to get from 2.0 to a late 2.1.x kernel,
x86 CPUs for example have more than doubled in clock rates, with an
almost linear increase in compilation speeds.
Conclusion: if you want faster compilations, get a faster CPU. Going
from Linux 2.0.x to 2.1.x will get you a negligible performance gain for
this kind of task.
The first step to correct benchmarking is to first identify the
bottleneck, then devise a benchmark that will effectively test this
bottleneck. Kernel compilation, for example, is a nice test for CPU
integer performance and cache/memory bandwidth. It's a poor benchmark
for kernel performance.
Shameless plug: if this issue interests you, check my Linux Benchmarking
HOWTO, and also my articles on Linux Benchmarking in the Linux Gazette.
Regards,
-- Andrew- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html