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: <20150414111706.GC398@x4>
Date:	Tue, 14 Apr 2015 13:17:06 +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 11:16 +0200, Ingo Molnar wrote:
> 
> * Markus Trippelsdorf <markus@...ppelsdorf.de> wrote:
> 
> > 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.
> 
> Lets rename "Ingo's patch" to "code_align=1". The interesting one 
> would be to compare:
> 
>            code_align=1 + -fno-guess-branch-probability
> vs.
>      lto + code_align=1 + -fno-guess-branch-probability
> 
> I'd expect LTO to still be in the 5% reduction range.

Yes:

   text     data    bss     dec 
   7886231  970296  802816  9659343 lto + code_align=1 + -fno-guess-branch-probability  
   8398284  978512  811008 10187804 code_align=1 + -fno-guess-branch-probability 

> > -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.
> 
> I'm not so sure about that one, our data access patterns are usually a 
> lot more well thought out than our code alignment (which is really 
> mostly compiler controlled). It also gives limited savings:
> 
>   9202488 vmlinux gcc-5
>   9186105 vmlinux gcc-5 (-malign-data=abi)
> 
> Which is 0.1%. I've got a handful of options in that size range:
> 
> +        # Reduces vmlinux size by 0.25%:
> +        KBUILD_CFLAGS += -fno-caller-saves
> +
> +        # Reduces vmlinux size by 1.10%:
> +        KBUILD_CFLAGS += -fno-inline-small-functions
> +
> +        # Reduces vmlinux size by about 0.95%:
> +        KBUILD_CFLAGS += -fno-tree-ch
> 
> but obviously they are more obscure and thus riskier. Find below an 
> updated "Ingo's combo patch". It gives more than 10% savings here on 
> x86 defconfig using gcc 4.9, without LTO.

Well obviously, if you do not care about performance you can reduce the
text size further and further. But what is interesting is to keep the
performance up (or even increase it) and still reduce the text size.
And that is what the "lto + Ingo's patch + -malign-data=abi" kernel
hopefully achieves (, but it would need further benchmarking to confirm
this claim).

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