linux-kernel - Re: [GIT PULL] adaptive spinning mutexes

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]

Date:	Thu, 15 Jan 2009 17:01:32 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:	Ingo Molnar <mingo@...e.hu>, Matthew Wilcox <matthew@....cx>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Gregory Haskins <ghaskins@...ell.com>,
	Andi Kleen <andi@...stfloor.org>,
	Chris Mason <chris.mason@...cle.com>,
	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>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Johannes Weiner <hannes@...xchg.org>
Subject: Re: [GIT PULL] adaptive spinning mutexes

On Thu, 15 Jan 2009, Paul E. McKenney wrote:

> On Thu, Jan 15, 2009 at 10:16:53AM -0800, Linus Torvalds wrote:
> > 
> > IOW, if you do pre-allocation instead of holding a lock over the 
> > allocation, you win. So yes, spin-mutexes makes it easier to write the 
> > code, but it also makes it easier to just plain be lazy.
> 
> In infrequently invoked code such as some error handling, lazy/simple
> can be a big win.

Sure. I don't disagree at all. On such code we don't even care about 
locking. If it _really_ is fundamentally very rarely invoked.

But if we're talking things like core filesystem locks, it's _really_ 
irritating when one of those (supposedly rare) allocation delays or the 
need to do IO then blocks all those (supposedly common) nice cached cases.

So I don't dispute at all that "mutex with spinning" performs better than 
a mutex, but I _do_ claim that it has some potentially huge downsides 
compared to a real spinlock. It may perform as well as a spinlock in the 
nice common case, but then when you hit the non-common case you see the 
difference between well-written code and badly written code.

And sadly, while allocations _usually_ are nice and immediate, and while 
our caches _usually_ mean that we don't need to do IO, bad behavior when 
we do need to do IO is what really kills interactive feel. Suddenly 
everything else is hurting too, because they wanted that lock - even if 
they didn't need to do IO or allocate anything.

			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/