bsh@grotto.jp said:
>   The kernels were built from -current source as of 2004-Feb-04, with
> following changes:

>   2410-a: backed out both write-back dcache change and clocking-mode
>           bits fix in arm9_setup().
>           (using sys/arm/include/cpufunc.h:1.29, sys/arm/arm/
> cpufunc.c:1.65, 
>           sys/arm/arm/cpufunc_asm_arm9.S:1.2)

>   2410-b: with clocking-mode bits fix in arm9_setup(), and without
>           write-back d-cache.

>   2410-c: with write-back d-cache chages, and without clocking-mode
>           bits fix.

>   2410-d: both write-back d-cache changes and clocking-mode bits fix.

>   It showed that clocking-mode bits fix made better results for all
> tests, while write-back d-cache changes gave lower performance on some
> tests. 

Thanks for doing this.  Yes, I think these results are what one would 
expect empirically.

The clock speed improvements are universally good.  Why would running on a 
slower clock ever be better?

The dcache changes are good when you don't need cache flushes (the tests 
which do, such as context switching, suffer slightly as a result).

I think that on a real system these changes would be beneficial.  Do you 
have any other benchmark scores for the dcache changes?  Dhrystone scores 
would be interesting, for example (not so much the numbers but the 
relative scores).

Another useful test that I sometimes run is to time how long it takes to 
run the configure script for the 'GNU make' source package.

R.