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]

Date:	Thu, 08 Jan 2009 14:02:30 -0500
From:	Chris Mason <chris.mason@...cle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, paulmck@...ux.vnet.ibm.com,
	Gregory Haskins <ghaskins@...ell.com>,
	Matthew Wilcox <matthew@....cx>,
	Andi Kleen <andi@...stfloor.org>,
	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 Thu, 2009-01-08 at 13:27 -0500, Chris Mason wrote:
> On Thu, 2009-01-08 at 10:16 -0800, Linus Torvalds wrote:
> > 
> > On Thu, 8 Jan 2009, Steven Rostedt wrote:
> > > 
> > > Ouch! I think you are on to something:
> > 
> > Yeah, there's somethign there, but looking at Chris' backtrace, there's 
> > nothing there to disable preemption. So if it was this simple case, it 
> > should still have preempted him to let the other process run and finish 
> > up.
> > 
> 
> My .config has no lockdep or schedule debugging and voluntary preempt.
> I do have CONFIG_INLINE_OPTIMIZE on, its a good name for trusting gcc I
> guess.

The patch below isn't quite what Linus suggested, but it is working here
at least.  In every test I've tried so far, this is faster than the ugly
btrfs spin.

dbench v7.1:        789mb/s
dbench simple spin: 566MB/s

50 proc parallel creates v7.1:        162 files/s avg sys: 1.6
50 proc parallel creates simple spin: 152 files/s avg sys: 2

50 proc parallel stat v7.1:        2.3s total
50 proc parallel stat simple spin: 3.8s total

It is less fair though, the 50 proc parallel creates had a much bigger
span between the first and last proc's exit time.  This isn't a huge
shock, I think it shows the hot path is closer to a real spin lock.

Here's the incremental I was using.  It looks to me like most of the
things that could change inside spin_on_owner mean we still want to
spin.  The only exception is the need_resched() flag.

-chris

diff --git a/kernel/mutex.c b/kernel/mutex.c
index bd6342a..8936410 100644
--- a/kernel/mutex.c
+++ b/kernel/mutex.c
@@ -161,11 +161,13 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 			return 0;
 		}
 
-		if (old_val < 0 && !list_empty(&lock->wait_list))
+		if (!list_empty(&lock->wait_list))
 			break;
 
 		/* See who owns it, and spin on him if anybody */
 		owner = ACCESS_ONCE(lock->owner);
+		if (need_resched())
+			break;
 		if (owner && !spin_on_owner(lock, owner))
 			break;
 


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