svn commit: r314669 - head/sys/i386/conf

[John Baldwin]

On Saturday, March 04, 2017 08:14:11 PM Pedro Giffuni wrote:
> 
> 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 <jhb at freebsd.org> ha scritto:
> >>>
> >>> 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:
> >>>>>
> >>>>>> Author: pfg
> >>>>>> Date: Sat Mar  4 15:04:17 2017
> >>>>>> New Revision: 314669
> >>>>>> URL: https://svnweb.freebsd.org/changeset/base/314669
> >>>>>>
> >>>>>> Log:
> >>>>>>   Drop i486 from the default i386 GENERIC kernel configuration.
> >>>>>>
> >>>>>>   80486 production was stopped by Intel on September 2007. Dropping the 486
> >>>>>>   configuration option from the GENERIC kernel improves performance
> >>>>>>   slightly.
> >>>>>>
> >>>>>>   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.
> >>>
> >> 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. :-/
> >
> > Nothing for other CPUs has changed.
> 
> Not much has been lost then.
> FWIW, I have a "Pentium overdrive" somewhere in the basement which could 
> theoretically boot FreeBSD 12 but last I remember just rebuilding a 
> kernel was painful and the memory and HD limitations really make it a no-go.

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.

-- 
John Baldwin