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: <20150414082346.GB398@x4>
Date:	Tue, 14 Apr 2015 10:23:46 +0200
From:	Markus Trippelsdorf <markus@...ppelsdorf.de>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	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.14 at 07:38 +0200, Ingo Molnar wrote:
> 
> Just to make sure, could you please also apply the 3 alignment patches 
> attached below? There's a lot of noise from extra alignment.

Here's an updated table:

   text    data     bss     dec     filename
   8746230  970072  802816 10519118 ./vmlinux gcc-5 (lto) 
   9202488  978512  811008 10992008 ./vmlinux gcc-5
   8036915  970296  802816 9810027  ./vmlinux gcc-5 (lto -fno-guess-branch-probability)
   8593615  978512  811008 10383135 ./vmlinux gcc-5 (-fno-guess-branch-probability)
   8202614  970072  802816 9975502  ./vmlinux gcc-5 (lto + Ingo's patch)
   8801016  978512  811008 10590536 ./vmlinux gcc-5 (Ingo's patch) 
   8733943  952088  798720 10484751 ./vmlinux gcc-5 (lto + -malign-data=abi)
   9186105  958320  806912 10951337 ./vmlinux gcc-5 (-malign-data=abi)
   8190327  952088  798720 9941135  ./vmlinux gcc-5 (lto + Ingo's patch + -malign-data=abi)
   8784633  958320  806912 10549865 ./vmlinux gcc-5 (Ingo's patch + -malign-data=abi) 

For the "lto + Ingo's patch + -malign-data=abi" combination there is a
10% text size reduction.

-malign-data is a new option for gcc-5 that controls how the compiler
aligns variables. "abi" aligns variables according to psABI and give the
tightest packing. 
"compat" is the default and uses an increased alignment value compatible
with gcc-4.8. But this should be unnecessary for the kernel. 
(The other possible value is "cache", which increases the alignment
value to match the cache line size.)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5ba2d9ce82dc..93702eef1684 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -77,6 +77,9 @@ else
         KBUILD_AFLAGS += -m64
         KBUILD_CFLAGS += -m64
 
+        # Align variables according to psABI
+        KBUILD_CFLAGS += -malign-data=abi
+
         # Don't autogenerate traditional x87 instructions
         KBUILD_CFLAGS += $(call cc-option,-mno-80387)
         KBUILD_CFLAGS += $(call cc-option,-mno-fp-ret-in-387)

> Having said that, LTO should have three main effects:
> 
>  1) better cross-unit inlining decisions
> 
>  2) better register allocation and clobbering knowledge (if a small 
>     function is known not to clobber caller-saved registers, then the 
>     saving can be skipped)
> 
>  3) better dead code elimination
> 
> 1)-2) is probably worth the price, 3) in isolation isn't. So we'd have 
> to estimate which one is how significant, to judge the value of LTO - 
> but I haven't seen any effort so far to disambiguate it.

For a high level overview of LTO in gcc-5 see Honza's recent article:
http://hubicka.blogspot.de/2015/04/GCC5-IPA-LTO-news.html

I haven't looked at the generated code at all yet, because the kernel is
huge and I'm not sure where to best look for specific changes.

> _Possibly_ if you build kernel/built-in.o only, and compared its 
> sizes, that would help a bit, because the core kernel has very little 
> dead code, giving a fairer estimation of 'true' optimizations.

This isn't possible, because kernel/built-in.o is a 'slim' lto object
file, that only contains compressed LTO sections with the compiler's
internal representation.

-- 
Markus
--
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/