From owner-freebsd-stable@FreeBSD.ORG Thu Dec 15 04:05:05 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 AF88316A41F for ; Thu, 15 Dec 2005 04:05:05 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from smtp101.biz.mail.mud.yahoo.com (smtp101.biz.mail.mud.yahoo.com [68.142.200.236]) by mx1.FreeBSD.org (Postfix) with SMTP id 25D1B43D53 for ; Thu, 15 Dec 2005 04:05:05 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: (qmail 82817 invoked from network); 15 Dec 2005 04:05:04 -0000 Received: from unknown (HELO optimator.noacks.org) (noackjr@supercrime.org@24.99.22.177 with login) by smtp101.biz.mail.mud.yahoo.com with SMTP; 15 Dec 2005 04:05:04 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 6AAB861A4; Wed, 14 Dec 2005 23:05:03 -0500 (EST) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 55448-15; Wed, 14 Dec 2005 23:05:02 -0500 (EST) Received: from [192.168.1.9] (bastion.noacks.org [192.168.1.9]) by optimator.noacks.org (Postfix) with ESMTP id 2775060D5; Wed, 14 Dec 2005 23:05:02 -0500 (EST) Message-ID: <43A0EB72.8060908@alumni.rice.edu> Date: Wed, 14 Dec 2005 23:05:06 -0500 From: Jonathan Noack User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Scott Long References: <20051215002618.B4D3B5D07@ptavv.es.net> <43A0E607.2030101@alumni.rice.edu> <43A0E916.7070204@samsco.org> In-Reply-To: <43A0E916.7070204@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at noacks.org Cc: stable@freebsd.org Subject: Re: kernel cpu entries X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: noackjr@alumni.rice.edu 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 04:05:05 -0000 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. > > 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 =-) It's even a project idea: http://www.freebsd.org/projects/ideas/#p-memcpy -Jonathan