From owner-svn-src-head@FreeBSD.ORG Fri Mar 19 21:55:23 2010 Return-Path: Delivered-To: svn-src-head@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E920A106566B; Fri, 19 Mar 2010 21:55:23 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id A66D48FC1A; Fri, 19 Mar 2010 21:55:23 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id o2JLtM1J092306; Fri, 19 Mar 2010 17:55:22 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id o2JLtM3G092305; Fri, 19 Mar 2010 17:55:22 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 19 Mar 2010 17:55:22 -0400 From: David Schultz To: Bruce Evans Message-ID: <20100319215522.GA91882@zim.MIT.EDU> Mail-Followup-To: Bruce Evans , John Baldwin , Xin LI , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201003190116.o2J1Gr2v094129@svn.freebsd.org> <201003190759.56385.jhb@freebsd.org> <20100320002555.I1181@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100320002555.I1181@delplex.bde.org> Cc: svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, src-committers@FreeBSD.ORG, Xin LI , John Baldwin Subject: Re: svn commit: r205307 - head/sys/i386/conf X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 21:55:24 -0000 On Sat, Mar 20, 2010, Bruce Evans wrote: > The effect of I486_CPU is especially small. > It is: > - statically disable use of the TSC in the bogus get_cyclecount() API. > Although the TSC is dynamically configured elsewhere, this function > wants to use the TSC without any dynamic tests, so it is uses static > configuration for efficiency. > - avoid compiling in functions to initialize a 486. There is dynamic > code to use these functions as needed, but this optimization saves > a few hundred if not a few thousand bytes. > - panic if the CPU is an i486, since the necessary extra support for > an i486 (just the above 2 features) is not present. > I586_CPU gives a little more. E.g., support for fixing the F00F hardware > bug on some Pentium1's. Again there is dynamic configuration for this > but a few hundred bytes are saved by not compiling it in. Agreed, these options make very little difference right now, but they *could* have a bigger impact. Other operating systems have completely deprecated older CPUs in order to take better advantage of new features than FreeBSD does. For instance, Solaris 10 requries CMPXCHG8B, which is needed to implement correct lock-free queues that are efficient enough to be useful. Supposedly this is a big win under high contention. Windows XP and later also require CMPXCHG8B. The catch, of course, is that if you write a scheduler to take advantage of lock-free queues, expensive emulation (spinlocks) will be required to make it work on hardware without the necessary support. Merely *having* a supported I486_CPU knob makes design choices like these seem unattractive. Another concrete example: We don't properly save/restore the SSE state in setjmp() on i386 because it's cumbersome to do this and without breaking older CPUs.