From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752355AbbDNFif (ORCPT ); Tue, 14 Apr 2015 01:38:35 -0400 Received: from mail-wg0-f46.google.com ([74.125.82.46]:36196 "EHLO mail-wg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751189AbbDNFi0 (ORCPT ); Tue, 14 Apr 2015 01:38:26 -0400 Date: Tue, 14 Apr 2015 07:38:21 +0200 From: Ingo Molnar To: Markus Trippelsdorf Cc: Linus Torvalds , "H. Peter Anvin" , Denys Vlasenko , "Paul E. McKenney" , Jason Low , Peter Zijlstra , Davidlohr Bueso , Tim Chen , Aswin Chandramouleeswaran , LKML , Borislav Petkov , Andy Lutomirski , Brian Gerst , Thomas Gleixner , Peter Zijlstra Subject: Re: [PATCH] x86: Align jump targets to 1 byte boundaries Message-ID: <20150414053821.GA28321@gmail.com> References: <20150410112748.GB30477@gmail.com> <20150410120846.GA17101@gmail.com> <5527C700.3030405@redhat.com> <5527CD92.1080901@zytor.com> <20150411144135.GB31416@x4> <20150412101422.GA2862@gmail.com> <20150413162308.GB398@x4> <20150413172624.GC398@x4> <20150413190914.GA398@x4> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150413190914.GA398@x4> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Markus Trippelsdorf wrote: > On 2015.04.13 at 11:31 -0700, Linus Torvalds wrote: > > On Mon, Apr 13, 2015 at 10:26 AM, Markus Trippelsdorf > > wrote: > > > > > > I must have made a measurement mistake above, because the actual code > > > size savings are roughly 5%: > > > > Can you check against the -fno-guess-branch-probability output? > > 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) Just to make sure, could you please also apply the 3 alignment patches attached below? There's a lot of noise from extra alignment. 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. _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. Thanks, Ingo ====== arch/x86/Makefile | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 5ba2d9ce82dc..10989a73b986 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -77,6 +77,15 @@ else KBUILD_AFLAGS += -m64 KBUILD_CFLAGS += -m64 + # Pack jump targets tightly, don't align them to the default 16 bytes: + KBUILD_CFLAGS += -falign-jumps=1 + + # Pack functions tightly as well: + KBUILD_CFLAGS += -falign-functions=1 + + # Pack loops tightly as well: + KBUILD_CFLAGS += -falign-loops=1 + # Don't autogenerate traditional x87 instructions KBUILD_CFLAGS += $(call cc-option,-mno-80387) KBUILD_CFLAGS += $(call cc-option,-mno-fp-ret-in-387)