I found your post very interesting, specially the conclusion:
....
> It looks like, for "normal" work, the difference is virtually nonexistent,
> and totally overshadowed by the effects of usage patterns, resulting in any
> actual effect being below the noise level of general measures.
This is 100% correct: applying -fno-strength-reduce to a kernel is hardly
reflected on the performance of this kernel, as measured by the "standard"
kernel compilation benchmark (or any other large compilation job).
I have proposed kernel compilation times in the Linux Benchmarking HOWTO as a
measurement of general CPU/memory/cache performance. It is a "typical" Linux
user job, and the 2.0 source is often available from some old CD-ROM that Linux
users may have lying around, so we can even get comparable benchmark results
across a wide range of systems. OTOH, it is a very poor benchmark for kernel
performance, because it is not kernel bound.
We know things like the dcache can provide noticeably improved performance
in some cases, just like devfs and other kernel _algorithmic_ improvements (and
devfs has some other neat qualities too). Similarly, improved drivers like the
IDE DMA driver provide significant performance gains, because they effectively
use the best hardware features at/near their maximum theoretical performance.
But tweaking gcc settings for the Linux kernel beyond its present settings
rarely if ever results in measurable kernel performance gains. Similarly with
"code improvements" that shave off a few nanoseconds, but decrease
maintainability and robustness of the previous code.
The conclusion is that it is very hard to come up with actual measurements of
kernel-bound system performance i.e. nobody has come up yet with a Khernelstone
metric :-)
This in fact is a consequence of Amdahl's Law: most jobs spends so little time
in the kernel routines themselves, that whatever kernel performance
improvements we may come up with will inevitably be hardly measurable compared
to the overall job duration.
Perhaps this should ring an alarm for kernel developers. Right now we should
perhaps think of improvements in the set of services provided by the kernel,
quality of code (maintainability and documentation), and general kernel
flexibility, instead of concentrating solely on performance metrics, which is a
somewhat short-sighted view on kernel functionality.
Cheers,
-- Andrew D. Balsa andrebalsa@altern.org
- 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