linux-kernel - Re: [PATCH] x86: Align jump targets to 1 byte boundaries

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]

Message-ID: <20150413172624.GC398@x4>
Date:	Mon, 13 Apr 2015 19:26:24 +0200
From:	Markus Trippelsdorf <markus@...ppelsdorf.de>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jason Low <jason.low2@...com>,
	Peter Zijlstra <peterz@...radead.org>,
	Davidlohr Bueso <dave@...olabs.net>,
	Tim Chen <tim.c.chen@...ux.intel.com>,
	Aswin Chandramouleeswaran <aswin@...com>,
	LKML <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>,
	Andy Lutomirski <luto@...capital.net>,
	Brian Gerst <brgerst@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] x86: Align jump targets to 1 byte boundaries

On 2015.04.13 at 18:23 +0200, Markus Trippelsdorf wrote:
> On 2015.04.12 at 12:14 +0200, Ingo Molnar wrote:
> > In my (past) experience the main win from -flto is not due to better 
> > hot/cold decisions, but simply due to more aggressive dead code 
> > elimination. -flto has less of an effect on code that is actually 
> > being executed.
> > 
> > Which isn't to be sneered at, but it's far less of a direct effect as 
> > branch probabilities are, which cut to the core of most hotpaths in 
> > the kernel.
> 
> I did some measurements with gcc-5.1-RC on X86_64 using Andi's latest
> LTO kernel patch for 4.0. With my simple monolithic .config the code
> size savings are below 1%. That is lower than I've expected.

I must have made a measurement mistake above, because the actual code
size savings are roughly 5%:

   text    data     bss     dec     filename
   8746230  970072  802816 10519118 ./vmlinux gcc-5 (lto) 
   9202488  978512  811008 10992008 ./vmlinux gcc-5
   8686246 1009104  811008 10506358 ./vmlinux gcc-4.9 (lto)
   9228994  992976  815104 11037074 ./vmlinux gcc-4.9 

-- 
Markus

View attachment "config" of type "text/plain" (71759 bytes)