linux-kernel - Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

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]

Message-ID: <20090109231227.GA25070@elte.hu>
Date:	Sat, 10 Jan 2009 00:12:27 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Harvey Harrison <harvey.harrison@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
	Chris Mason <chris.mason@...cle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	paulmck@...ux.vnet.ibm.com, Gregory Haskins <ghaskins@...ell.com>,
	Matthew Wilcox <matthew@....cx>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nick Piggin <npiggin@...e.de>,
	Peter Morreale <pmorreale@...ell.com>,
	Sven Dietrich <SDietrich@...ell.com>
Subject: Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, 9 Jan 2009, Harvey Harrison wrote:
> > 
> > __needs_inline?  That would imply that it's for correctness reasons.
> 
> .. but the point is, we have _thousands_ of inlines, and do you know 
> which is which? We've historically forced them to be inlined, and every 
> time somebody does that "OPTIMIZE_INLINE=y", something simply _breaks_.

Having watched all the inline and anti-inline activites and patches of the 
past decade (and having participated in many of them) my strong impression 
is that any non-automated way is a fundamentally inhuman Don Quijote 
fight.

The inlining numbers me and others posted seem to support that impression.

Today we have in excess of thirty thousand 'inline' keyword uses in the 
kernel, and in excess of one hundred thousand kernel functions. We had a 
decade of hundreds of inline-tuning patches that flipped inline attributes 
on and off, with the goal of doing that job better than the compiler.

Still a sucky compiler who was never faced with this level of inlining 
complexity before (up to a few short months ago when we released the first 
kernel with non-CONFIG_BROKEN-marked CONFIG_OPTIMIZE_INLINING feature in 
it) manages to do a better job at judging inlining than a decade of human 
optimizations managed to do. (If you accept that 1% - 3% - 7.5% code size 
reduction in important areas of the kernel is an improvement.)

That improvement is systematic: it happens regardless whether it's core 
kernel developers who wrote the code, with years of kernel experience - or 
driver developers who came from Windows and might be inexperienced about 
it all and might slap 'inline' on every second random function.

And it's not like the compiler was not allowed to inline important 
functions before: all static functions in .c it can (and do) inline if it 
sees fit. Tens of thousands of them.

If we change 'inline' back to mean 'must inline' again, we have not 
changed the human dynamics of inlines at all and are back on square one. 
'should_inline' or 'may_inline' will be an opt-in hint that will be 
subject to the same kind of misjudgements that resulted in the inlining 
situation to begin with. In .c files it's already possible to do that: by 
not placing an 'inline' keyword at all, just leaving the function 
'static'.

may_inline/inline_hint is a longer, less known and uglier keyword. So all 
the cards are stacked up against this new 'may inline' mechanism, and by 
all likelyhood it will fizzle and never reach any sort of critical mass to 
truly matter. Nor should it - why should humans do this if a silly tool 
can achieve something rather acceptable?

So such a change will in essence amount to the effective removal of 
CONFIG_OPTIMIZE_INLINING. If we want to do that then we should do that 
honestly - and remove it altogether and not pretend to care.

Fedora has CONFIG_OPTIMIZE_INLINING=y enabled today - distros are always 
on the lookout for kernel image reductor features. As of today i'm not 
aware of a single Fedora bugzilla that was caused by that.

The upstream kernel did have bugs due to it - we had the UML breakage for 
example, and an older 3.x gcc threw an internal error on one of the 
(stale) isdn telephony drivers. Was Chris's crash actually caused by gcc's 
inlining decisions? I dont think it was.

Historically we had far more compiler problems with 
CONFIG_CC_OPTIMIZE_SIZE=y - optimizing for size is a subtly complex and 
non-trivial compiler pass.

	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/