From owner-svn-src-head@freebsd.org Mon Mar 6 02:42:41 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FAC9CF9D8A for ; Mon, 6 Mar 2017 02:42:41 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id 0303214B1 for ; Mon, 6 Mar 2017 02:42:40 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: (qmail 34736 invoked by uid 99); 6 Mar 2017 02:42:39 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Mar 2017 02:42:39 +0000 Received: from [192.168.0.104] (unknown [190.157.139.67]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id BD0A81A0995; Mon, 6 Mar 2017 02:42:37 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: svn commit: r314669 - head/sys/i386/conf From: Pedro Giffuni In-Reply-To: <1537596.qhqdTsTLLF@ralph.baldwin.cx> Date: Sun, 5 Mar 2017 21:43:03 -0500 Cc: Slawa Olhovchenkov , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3351E9C7-CC12-472A-9E81-4973710E9C8C@FreeBSD.org> References: <201703041504.v24F4HMh023937@repo.freebsd.org> <7873439.f6BlOXHt6g@ralph.baldwin.cx> <1537596.qhqdTsTLLF@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.3259) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 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: Mon, 06 Mar 2017 02:42:41 -0000 > Il giorno 05 mar 2017, alle ore 18:24, John Baldwin = ha scritto: >=20 > On Saturday, March 04, 2017 08:14:11 PM Pedro Giffuni wrote: >>=20 >> On 3/4/2017 5:51 PM, John Baldwin wrote: >>> On Saturday, March 04, 2017 03:49:52 PM Pedro Giffuni wrote: >>>>> Il giorno 04 mar 2017, alle ore 14:43, John Baldwin = ha scritto: >>>>>=20 >>>>> On Saturday, March 04, 2017 10:52:46 AM Pedro Giffuni wrote: >>>>>> On 03/04/17 10:32, Slawa Olhovchenkov wrote: >>>>>>> On Sat, Mar 04, 2017 at 03:04:17PM +0000, Pedro F. Giffuni = wrote: >>>>>>>=20 >>>>>>>> Author: pfg >>>>>>>> Date: Sat Mar 4 15:04:17 2017 >>>>>>>> New Revision: 314669 >>>>>>>> URL: https://svnweb.freebsd.org/changeset/base/314669 >>>>>>>>=20 >>>>>>>> Log: >>>>>>>> Drop i486 from the default i386 GENERIC kernel configuration. >>>>>>>>=20 >>>>>>>> 80486 production was stopped by Intel on September 2007. = Dropping the 486 >>>>>>>> configuration option from the GENERIC kernel improves = performance >>>>>>>> slightly. >>>>>>>>=20 >>>>>>>> Removing I486_CPU is consistent at this time: we don't support = any >>>>>>>> processor without a FPU and the PC-98 arch, which frequently = involved i486 >>>>>>>> CPUs, is also gone so we don't test such platforms anymore. >>>>>>> What is realy mean? >>>>>> This means we don't do work-arounds that would be required for = raw 486. >>>>>> Instead we will use the 586 instructions by default. >>>>> This doesn't change that. The kernel already has runtime tests in = place >>>>> for new things on 486 and later via cpuid. >>>>>=20 >>>> Hmm ..then I am wondering if I effectively changed anything? >>> The only change is a 486 now panics on boot when it used to work = fine. :-/ >>>=20 >>> Nothing for other CPUs has changed. >>=20 >> Not much has been lost then. >> FWIW, I have a "Pentium overdrive" somewhere in the basement which = could=20 >> theoretically boot FreeBSD 12 but last I remember just rebuilding a=20= >> kernel was painful and the memory and HD limitations really make it a = no-go. >=20 > So I would rather support 486 in GENERIC or not support it at all. It = doesn't > cost anything for it to be in GENERIC, so if we have it, I think we = should ship > it. Also, the original justification for this commit of a 4% = performance gain > doesn't seem to have any basis in fact. The one gain I can think of = is > de-cluttering some things like identcpu.c and initcpu.c which can only = happen if > we remove code entirely, not from removing an option in GENERIC. >=20 OK, that=E2=80=99s reasonable. I will revert the change. Pedro.