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