kernel cpu entries
Scott Long
scottl at samsco.org
Wed Dec 14 19:55:16 PST 2005
Jonathan Noack wrote:
> Kevin Oberman wrote:
>
>> 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.
>>
>>
>> Ahh, This is the sort of thing I never realized. Is there anything in
>> the handbook that covers this? I had always been under the impression
>> that CPU_I686 enabled all things that the 686 was capable of. I will
>> build a new kernel to add that back in.
>
>
> From tuning(7):
> **************************************************
> There are a number of *_CPU options that can be commented out. If you
> only want the kernel to run on a Pentium class CPU, you can easily
> remove I486_CPU, but only remove I586_CPU if you are sure your CPU is
> being recognized as a Pentium II or better. Some clones may be
> recognized as a Pentium or even a 486 and not be able to boot without
> those options. If it works, great! The operating system will be able
> to better use higher-end CPU features for MMU, task switching, timebase,
> and even device operations...
> **************************************************
>
> From /sys/i386/conf/NOTES:
> **************************************************
> # You must specify at least one CPU (the one you intend to run on);
> # deleting the specification for CPUs you don't need to use may make
> # parts of the system run faster.
> **************************************************
>
> From npx(4) (also see /sys/i386/i386/support.s):
> **************************************************
> The NPX registers are normally used to optimize copying and zeroing when
> all of the following conditions are satisfied:
> 1. cpu I586_CPU is an option
> ...
> Then copying and zeroing using the NPX registers is normally 30-100%
> faster.
> **************************************************
>
> All is rosy until you see that I586_CPU looks like a loss for blowfish
> (if you have an i686 CPU):
> /sys/crypto/blowfish/arch/i386/bf_enc.S
>
> As I use AES, I guess I586_CPU is a win for me. Despite this, I think
> it makes the most sense for I686_CPU to enable the optimized bcopy if it
> really is a win for i686 CPUs.
>
> -Jonathan
I agree, but frankly I've been loath to touch it out of pure fear of the
correctness geeks. I know that if I go near it, someone will point out
that it's not 100% correct in all cases of some buggy i686 derivative
that hasn't been sold since 1998, and therefore it's better to just
leave it alone and satify that .00001% of the problem. Or, the
alternate scenario is that people will moan that we should be using
SSE instead, and that any change that doesn't involve SSE is wrong and
a waste of time. Then a meta-argument will break out over SSE vs SSE2
vs 3DNow, and how again some buggy derivative chip can't use it and
can't be detected or worked around. I make my peace by just remembering
to leave CPU_I586 enabled on all of my local systems =-)
Scott
More information about the freebsd-stable
mailing list