linux-kernel - Re: [PATCH] force inlining of spinlock ops

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 13 May 2015 12:43:05 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Denys Vlasenko <dvlasenk@...hat.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Graf <tgraf@...g.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Bart Van Assche <bvanassche@....org>,
	Peter Zijlstra <peterz@...radead.org>,
	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] force inlining of spinlock ops


* Denys Vlasenko <dvlasenk@...hat.com> wrote:

> On 05/13/2015 12:17 PM, Ingo Molnar wrote:
> >>> In any case, the interesting measurement would not be -Os comparisons 
> >>> (which causes GCC to be too crazy), but to see the size effect of your 
> >>> _patch_ that always-inlines spinlock ops, on plain defconfig and on 
> >>> defconfig-Os.
> >>
> >> Here it is:
> >>
> >>     text    data     bss      dec    hex filename
> >> 12335864 1746152 1081344 15163360 e75fe0 vmlinuxO2.before
> >> 12335930 1746152 1081344 15163426 e76022 vmlinux
> > 
> > Hm, that's a (small) size increase on O2.
> > 
> > That might be a net positive though: because now we've eliminated 
> > quite a few function calls. Do we know which individual functions 
> > bloat and which debloat?
> 
> >>     text    data     bss      dec    hex filename
> >> 10373764 1684200 1077248 13135212 c86d6c vmlinuxOs.before
> >> 10363621 1684200 1077248 13125069 c845cd vmlinux
> > 
> > A decrease - which gets exploded on allyesconfig.
> > 
> > So as long as the -O2 case does not get hurt we can do -Os fixes.
> > 
> > I think this needs a bit more work to ensure that the O2 case is a 
> > net win.
> 
> I think O2 difference is just noise: with -O2 gcc is far less prone 
> to bogus deinlining, my patch should have negligible effect. And 
> effect is indeed negligible: +70 bytes on 12 megabytes.

So the patch force-inlines about a dozen locking APIs:

 - Some of those decrease the defconfig kernel size.
   Which ones and by how much?

 - Some of those increase the defconfig kernel size.
   Which ones and by how much?

We only know that the net effect is +70 bytes. Does that come out of:

 - large fluctuations such as -1000-1000+1000+1070, which happens to 
   net out into a small net number?

 - or does it come from much smaller fluctuations?

So to make an informed decision we need to know those details. When I 
deinline or reinline functions I usually do it on a per function 
basis, to avoid such ambiguity.

In the end what we want to have is only those deinlining/reinlining 
changes that decrease the defconfig kernel size, or at worst only 
increase it marginally.

Thanks,

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