kernel cpu entries

[Anish Mistry]

On Wednesday 14 December 2005 10:55 pm, 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 =-)
>
> Scott
I too fall into the "I had no idea!" camp.  This seems a bit silly 
just to satisfy a very small and unknown group of broken chips.  
Couldn't the optimized bcopy be enabled with I686_CPU, and also an 
option like NO_OPTIMIZED_BCOPY and an UPDATING entry that would tell 
those .00001% to make that change so their system doesn't break?  
Would this be an acceptable solution?

-- 
Anish Mistry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20051215/32bda2e2/attachment.bin