From owner-freebsd-stable@FreeBSD.ORG Thu Dec 15 05:53:31 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BE5716A445 for ; Thu, 15 Dec 2005 05:53:31 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id E59C043D5A for ; Thu, 15 Dec 2005 05:53:30 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id jBF5uM7Y034289 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 15 Dec 2005 00:56:28 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-stable@freebsd.org Date: Thu, 15 Dec 2005 00:55:32 -0500 User-Agent: KMail/1.8.3 References: <20051215002618.B4D3B5D07@ptavv.es.net> <43A0E607.2030101@alumni.rice.edu> <43A0E916.7070204@samsco.org> In-Reply-To: <43A0E916.7070204@samsco.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9687671.stBZ66knZu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512150055.39521.mistry.7@osu.edu> X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,BAYES_50, MYFREEBSD2 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.87/1209/Mon Dec 12 10:48:01 2005 on mail.united-ware.com X-Virus-Status: Clean Cc: Subject: Re: kernel cpu entries X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2005 05:53:31 -0000 --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--