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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.LFD.2.00.0901091731130.6528@localhost.localdomain>
Date:	Fri, 9 Jan 2009 17:34:09 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
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



On Sat, 10 Jan 2009, Ingo Molnar wrote:

> 
> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> > On Sat, 10 Jan 2009, Ingo Molnar wrote:
> > > 
> > > Well, it's not totally meaningless. To begin with, defining 'inline' to 
> > > mean 'always inline' is a Linux kernel definition. So we already changed 
> > > the behavior - in the hope of getting it right most of the time and in the 
> > > hope of thus improving the kernel.
> > 
> > Umm. No we didn't. We've never changed it. It was "always inline" back in 
> 
> s/changed the behavior/overrode the behavior

The point is, as far as the kenrel has been concerned, "inline" has always 
meant the same thing. Not just for the last few weeks, but for the last 18 
_years_. It's always meant "always inline".

> But i'd definitely argue that the Linux kernel definition of 'inline' was 
> always more consistent than GCC's. That was rather easy as well: it doesnt 
> get any more clear-cut than 'always inline'.

Exactly. And I argue that we shouldn't change it.

If we have too many "inline"s, and if gcc inlines for us _anyway_, then 
the answer is not to change the meaning of "inline", but simply say "ok, 
we have too many inlines. Let's remove the ones we don't care about".

> I think it is axiomatic that improving the kernel means changing it - 
> sometimes that means changing deep details. (And if you see us ignoring 
> complaints, let us know, it must not happen.)

And I'm agreeing with you.

What I'm _not_ agreeing with is how you want to change the semantics of 
something we've had for 18 years.

YOU are the one who want to make "inline" mean "maybe". I'm against it. 
I'm against it because it makes no sense. It's not what we've ever done.

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