Odd performance problems after upgrade from 4.11 to 6.0-Stable

Peter Jeremy PeterJeremy at optushome.com.au
Thu Dec 15 00:10:25 PST 2005


On Wed, 2005-Dec-14 16:17:38 -0700, Scott Long wrote:
>Also, taking out CPU_I586 is usually a bad idea.  It offers no 
>performance penalties (unlike CPU_I386 and maybe CPU_I486), but
>enables things like optimized bcopy.

This doesn't quite mesh with my reading of -current and -stable.

The following refers only to x86 kernels.

Kernel references to {bcopy,bzero,copyin,copyout}() indirect
through {bcopy,bzero,copyin,copyout}_vector.  This is initialised
to generic_{bcopy,bzero,copyin,copyout} in i386/i386/support.s.

*_vector is over-ridden with optimised routines as follows:
bcopy_vector:
- (effectively) never
bzero_vector:
- i486_bzero if (cpu_class == CPUCLASS_486) in sys/i386/i386/identcpu.c
copyin_vector:
- (effectively) never
copyout_vector:
- (effectively) never

The i586 optimised routines are defined in sys/i386/i386/support.s but
(effectively) never used since v1.101 of sys/i386/isa/npx.c changed
'#ifdef I586_CPU' to '#ifdef I586_CPU_XXX' (in 2001/05/22 21:20:49).
Even then, they are inside if (cpu_class == CPUCLASS_586) which is not
true for P-II and later CPUs.

That said, it might be worthwhile revisiting the issue of cpu-specific
optimisations.  If there is better code then generic_*() for Athlon
or P4 CPUs, we should implement it.  If there isn't, we can get a
(slight) performance improvement by removing the indirection through
*_vector - I suspect that CPUs can't predict/pipeline an indirect
branch as well as a direct branch.  

-- 
Peter Jeremy


More information about the freebsd-stable mailing list