[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <496B7EBC.6020208@redhat.com>
Date: Mon, 12 Jan 2009 19:32:44 +0200
From: Avi Kivity <avi@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Gregory Haskins <ghaskins@...ell.com>,
Matthew Wilcox <matthew@....cx>,
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>
Subject: Re: [PATCH -v8][RFC] mutex: implement adaptive spinning
Peter Zijlstra wrote:
> Spinlocks can use 'pure' MCS locks.
>
How about this, then. In mutex_lock(), keep wait_lock locked and only
release it when scheduling out. Waiter spinning naturally follows. If
spinlocks are cache friendly (are they today?) we inherit that. If
there is no contention on the mutex, then we don't need to reacquire the
wait_lock on mutex_unlock() (not that the atomic op is that expensive
these days).
--
error compiling committee.c: too many arguments to function
--
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/
Powered by blists - more mailing lists