linux-kernel - Re: [PATCH] [3/5] Mark complex bitops.h inlines as __always

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: <20090107132653.GA22229@elte.hu>
Date:	Wed, 7 Jan 2009 14:26:53 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	akpm@...ux-foundation.org, x86@...nel.org,
	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] [3/5] Mark complex bitops.h inlines as __always_inline

* Andi Kleen <andi@...stfloor.org> wrote:

> > Your patch is wrong because it prevents a good compiler from doing the 
> > right inlining decisions.
> 
> One or two instruction bitops should be always inlined, not inlining 
> them always generates much worse code than inlining them. That's easy to 
> prove just based on code size: the call overhead is larger than the 
> inlined code.

You are arguing this backwards. Firstly, CONFIG_OPTIMIZE_INLINING is 
disabled by default. If you enable it, and if CONFIG_OPTIMIZE_INLINING=y 
creates a larger kernel for you, then either do not enable it - or send 
numbers so that we can see the true impact of this change.

Yes, simple functions should always be inlined, nobody will argue about 
that. But GCC's inliner will never be fixed (for the kernel domain at 
least) if we keep working it around and if we keep micro-managing it.

We work around GCC bugs only if it hurts visibly (and generally if it 
affects default-enabled features/optimizations): if it can be quantified 
either via stability/robustness problems or there's excesssive size / 
efficiency problems.

You simply have not made that argument via any numbers here. So i have no 
reason to take your patch just yet, unless you provide some clear, 
documented, measurable benefit.

	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/