From: David Laight <David.Laight@ACULAB.COM> To: 'Joe Perches' <email@example.com>, Arnd Bergmann <firstname.lastname@example.org>, "Oleksandr Natalenko" <email@example.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>, LKML <firstname.lastname@example.org>, X86 ML <email@example.com>, Andrew Morton <firstname.lastname@example.org> Subject: RE: [PATCH] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE_O3 for gcc >= 10 Date: Sun, 10 May 2020 18:58:24 +0000 [thread overview] Message-ID: <eeb52e23496f4730bb115d1e8c00743e@AcuMS.aculab.com> (raw) In-Reply-To: <email@example.com> 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)
next prev parent reply other threads:[~2020-05-10 18:58 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-07 22:45 Jason A. Donenfeld 2020-05-08 8:35 ` Peter Zijlstra 2020-05-08 9:02 ` Oleksandr Natalenko 2020-05-08 11:21 ` Jason A. Donenfeld 2020-05-08 11:33 ` Oleksandr Natalenko 2020-05-08 11:49 ` Arnd Bergmann 2020-05-08 12:07 ` Jason A. Donenfeld 2020-05-08 13:04 ` Arnd Bergmann 2020-05-08 15:06 ` Joe Perches 2020-05-08 15:09 ` Arnd Bergmann 2020-05-10 12:47 ` David Laight 2020-05-10 17:45 ` Joe Perches 2020-05-10 18:58 ` David Laight [this message] 2020-05-12 1:10 ` Masahiro Yamada 2020-05-11 21:57 ` [PATCH v2] " Jason A. Donenfeld 2020-05-12 0:04 ` Linus Torvalds 2020-05-12 0:09 ` Linus Torvalds 2020-05-12 0:43 ` Jason A. Donenfeld 2020-05-12 8:44 ` Richard Biener 2020-05-13 11:27 ` [PATCH] " Artem S. Tashkinov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=eeb52e23496f4730bb115d1e8c00743e@AcuMS.aculab.com \ --firstname.lastname@example.org \ --cc=Jason@zx2c4.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='RE: [PATCH] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE_O3 for gcc >= 10' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).