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

[Konstantin Belousov]

On Sat, Mar 04, 2017 at 03:49:52PM -0500, 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?
> 
> >>> Some Via CPU is like i486 (by instruction set).
> >>> 
> >>> CPU: VIA Ezra (800.04-MHz 686-class CPU)
> >>>  Origin="CentaurHauls"  Id=0x678  Family=0x6  Model=0x7  Stepping=8
> >>>  Features=0x803035<FPU,DE,TSC,MSR,MTRR,PGE,MMX>
> >>>  AMD Features=0x80000000<3DNow!>
> >>> 
> >> 
> >> 486 never had MMX extensions.
> >> This is a 686, performance should improve ~4%.
> > 
> > How did you measure the improvement?  Keeping I486_CPU doesn't really
> > do anything except remove a some #ifdef'd conditionals in identcpu.c
> > and initcpu.c.  It doesn't affect whether we use the TSC, MMX, etc.  Those
> > are all runtime checks based the CPU feature flags from cpuid.
> > 
> 
> The number came out from an old posting involving buildworld times, which I can???t find now :(.
> Things seem to have changed a lot: it was surely using GCC back then, I don???t believe clang does much distinction about 486 at all.
> 
> BTW, does it make sense to keep i586 in the configuration still? Both i486 and i586 were once removed but later re-instated in r205336.
> 
What did make significant impact on 32bit shared libraries some time ago
was to compile them with -mtune=i686. Default PIC prologue effectively
neutered return stack predictor, adding uneccessary overhead to already
expensive PIC code. I think that this is even measureable, i.e. it might
give >= 5% of difference.

I did not rechecked modern compilers WRT the generated PIC code, but I doubt
that the thing changed recently.

Several notes: -mtune is not -march, i.e. the code would be still targeted
for 486 instruction set, but scheduling is optimized for more modern CPUs.
Also, recent gcc puts specific meaning into -mtune=i686, interpreting it
as request for scheduling for generic modern CPUs.  We already compile
32bit compat libs on amd64 with -march=i686.

Working on this stuff would be much more useful than tweaking kernel config
for CPU detection.