linux-kernel - Re: [RFC] init.h: mark init functions hot instead of cold

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] [day] [month] [year] [list]

Date:	Sat, 9 May 2015 14:17:15 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	Rasmus Villemoes <linux@...musvillemoes.dk>,
	Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] init.h: mark init functions hot instead of cold

On Sat, May 09, 2015 at 02:17:39AM -0700, Andi Kleen wrote:
> On Sat, May 09, 2015 at 12:45:01AM +0200, Rasmus Villemoes wrote:
> > attribute((cold)) causes gcc to optimize the function for size rather
> > than speed. But since __init functions will be discarded anyway, I
> > don't see why memory should be a concern. On the contrary, everybody
> 
> It makes the bzImage smaller.
> A lot of people on smaller systems are interested in flash size.

True, but people interested in flash size can set
CONFIG_CC_OPTIMIZE_FOR_SIZE.

I would propose dropping "cold" and *not* adding "hot"; just let __init
functions get default optimizations.  People who set
CONFIG_CC_OPTIMIZE_FOR_SIZE should get similar size optimizations, and
people who don't will get GCC's normal optimizations, which should
provide much of the improved boot performance Rasmus observed.

Rasmus, can you confirm that just dropping cold 1) doesn't make the
kernel larger when building with CONFIG_CC_OPTIMIZE_FOR_SIZE, and 2)
gives approximately the same 2% performance benefit you observed?

> > wants their box to boot faster. Using the opposite attribute, hot,
> > causes gcc to optimize the functions more aggressively, possibly at
> > the expense of larger (.init).text. A completely unscientific test
> > showed about 2% faster boot time: I booted a kernel in qemu with and
> > without this patch five times each; the boot times were very stable in
> > each case, so I think the 2% is ok, but of course only applies to that
> > specific .config running in a virtual machine on my hardware.
> 
> 2% on boot is basically noise.

I disagree; there are people working on shaving milliseconds from boot.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/