kernel cpu entries

[Mark Kirkwood]

Scott Long wrote:
> 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 =-)

Is a minor update to the handbook needed in order avoid confusion then? 
e.g. I have been commenting out CPU_I586 on all my PIII systems in the 
(mistaken it would seem) belief that having CPU_I686 only was better.

cheers

Mark