From owner-freebsd-stable@FreeBSD.ORG Thu Dec 15 03:55:16 2005 Return-Path: X-Original-To: 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 254E416A41F for ; Thu, 15 Dec 2005 03:55:16 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A718A43D5E for ; Thu, 15 Dec 2005 03:55:13 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jBF3t1Ao008333; Wed, 14 Dec 2005 20:55:01 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43A0E916.7070204@samsco.org> Date: Wed, 14 Dec 2005 20:55:02 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: noackjr@alumni.rice.edu References: <20051215002618.B4D3B5D07@ptavv.es.net> <43A0E607.2030101@alumni.rice.edu> In-Reply-To: <43A0E607.2030101@alumni.rice.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: stable@freebsd.org 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 03:55:16 -0000 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