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
pgpfqJUmZ0fRK.pgp
Description: PGP signature
