Date: Thu, 15 Dec 2005 00:55:32 -0500 From: Anish Mistry <mistry.7@osu.edu> To: freebsd-stable@freebsd.org Subject: Re: kernel cpu entries Message-ID: <200512150055.39521.mistry.7@osu.edu> In-Reply-To: <43A0E916.7070204@samsco.org> References: <20051215002618.B4D3B5D07@ptavv.es.net> <43A0E607.2030101@alumni.rice.edu> <43A0E916.7070204@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart9687671.stBZ66knZu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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.=20 > > 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.=20 > > 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 =3D-) > > Scott I too fall into the "I had no idea!" camp. This seems a bit silly=20 just to satisfy a very small and unknown group of broken chips. =20 Couldn't the optimized bcopy be enabled with I686_CPU, and also an=20 option like NO_OPTIMIZED_BCOPY and an UPDATING entry that would tell=20 those .00001% to make that change so their system doesn't break? =20 Would this be an acceptable solution? =2D-=20 Anish Mistry --nextPart9687671.stBZ66knZu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDoQVbxqA5ziudZT0RAqaxAJ9ngOxxt8M9xhcwj6HIKPtCnw6JQgCfUFBk z4rbAN3ywa5EoxcpG0QTikk= =K6Ov -----END PGP SIGNATURE----- --nextPart9687671.stBZ66knZu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512150055.39521.mistry.7>