linux-kernel - RE: [PATCH] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 10 May 2020 18:58:24 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Joe Perches' <joe@...ches.com>, Arnd Bergmann <arnd@...db.de>,
        "Oleksandr Natalenko" <oleksandr@...hat.com>
CC:     "Jason A. Donenfeld" <Jason@...c4.com>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: RE: [PATCH] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE_O3 for
 gcc >= 10

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)