From owner-svn-src-head@freebsd.org Sat Mar 4 21:16:19 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 3E877CF53E8; Sat, 4 Mar 2017 21:16:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C03441F87; Sat, 4 Mar 2017 21:16:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v24LGBgp012732 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Mar 2017 23:16:11 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v24LGBgp012732 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v24LGBbu012730; Sat, 4 Mar 2017 23:16:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 4 Mar 2017 23:16:11 +0200 From: Konstantin Belousov To: Pedro Giffuni Cc: John Baldwin , Slawa Olhovchenkov , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r314669 - head/sys/i386/conf Message-ID: <20170304211611.GW2092@kib.kiev.ua> References: <201703041504.v24F4HMh023937@repo.freebsd.org> <20170304153228.GM15630@zxy.spb.ru> <2368011.hGEX4V32U5@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Sat, 04 Mar 2017 21:16:19 -0000 On Sat, Mar 04, 2017 at 03:49:52PM -0500, Pedro Giffuni wrote: > > > Il giorno 04 mar 2017, alle ore 14:43, John Baldwin 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 > >>> 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.