Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   David Laight <David.Laight@ACULAB.COM>
To:     'Joe Perches' <joe@perches.com>, Arnd Bergmann <arnd@arndb.de>,
        "Oleksandr Natalenko" <oleksandr@redhat.com>
CC:     "Jason A. Donenfeld" <Jason@zx2c4.com>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: RE: [PATCH] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE_O3 for
 gcc >= 10
Thread-Topic: [PATCH] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE_O3 for
 gcc >= 10
Thread-Index: AQHWJUo8bK79Vz6Er0qWTasVui4yHqihRWbAgABE0gCAABxpkA==
Date:   Sun, 10 May 2020 18:58:24 +0000
Message-ID: <eeb52e23496f4730bb115d1e8c00743e@AcuMS.aculab.com>
References: <20200507224530.2993316-1-Jason@zx2c4.com>
         <20200508090202.7s3kcqpvpxx32syu@butterfly.localdomain>
         <CAHmME9pTZTa9AEUL0-ojTr7P-F7NYe8OR9=-GBPaQNpnSDrEiw@mail.gmail.com>
         <20200508113336.2vdfdnc6tqyx4pu6@butterfly.localdomain>
         <CAK8P3a0dJ0vNnktcoWFiPKB4NJbeyf7nvwWf0YLyeUyxT5pvQg@mail.gmail.com>
         <c774d7371a9599526090e63e85f61e69bddf4795.camel@perches.com>
         <9590a4674863448e8b13fee5086fcf73@AcuMS.aculab.com>
 <c78e00a05d19a6823e48c7bd50144f0563908a1a.camel@perches.com>
In-Reply-To: <c78e00a05d19a6823e48c7bd50144f0563908a1a.camel@perches.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

From: Joe Perches
> Sent: 10 May 2020 18:45
> 
> On Sun, 2020-05-10 at 12:47 +0000, David Laight wrote:
> > From: Joe Perches
> > > Sent: 08 May 2020 16:06
> > > On Fri, 2020-05-08 at 13:49 +0200, Arnd Bergmann wrote:
> > > > Personally, I'm more interested in improving compile speed of the kernel
> > >
> > > Any opinion on precompiled header support?
> >
> > When ever I've been anywhere near it it is always a disaster.
> 
> A disaster? Why?

The only time I've had systems that used them they always got
out of step with the headers - probable due to #define changes.
If auto-generated by the compiler then parallel makes also
give problems.

> For a large commercial c only project, it worked well
> by reducing a combined multi-include file, similar to
> kernel.h here, to a single file.

Certainly reducing the number of directories searched
can make a big difference.

I've also compiled .so by merging all the sources into a
single file.

> That was before SSDs though and the file open times
> might have been rather larger then.

The real killer is lots of directory names in the -I <paths>
especially over NFS.

I've also looked at system call stats during a kernel compile.
open() dominated and my 'gut feeling' was that most were
failing opens.

I also suspect that modern compilers remember that an include
file contained an include guard - and don't even both looking
for it a second time.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)