lkml.org 
[lkml]   [2010]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [tip:core/locking] mutex: Fix optimistic spinning vs. BKL
On Tue, May 18, 2010 at 06:08:38PM +0200, Ingo Molnar wrote:
>
> * tip-bot for Tony Breeds <tony@bakeyournoodle.com> wrote:
>
> > Commit-ID: 227945799cc10d77c6ef812f3eb8a61a78689454
> > Gitweb: http://git.kernel.org/tip/227945799cc10d77c6ef812f3eb8a61a78689454
> > Author: Tony Breeds <tony@bakeyournoodle.com>
> > AuthorDate: Fri, 7 May 2010 14:20:10 +1000
> > Committer: Ingo Molnar <mingo@elte.hu>
> > CommitDate: Tue, 11 May 2010 17:07:24 +0200
> >
> > mutex: Fix optimistic spinning vs. BKL
>
> Tony, mind sending a version of this patch that does not
> include a jiffies based spinning loop?

Subject: [PATCH] mutex: Fix optimistic spinning vs. BKL

Currently, we can hit a nasty case with optimistic spinning on
mutexes:

CPU A tries to take a mutex, while holding the BKL

CPU B tried to take the BLK while holding the mutex

This looks like a AB-BA scenario but in practice, is allowed and
happens due to the auto-release-on-schedule nature of the BKL.

In that case, the optimistic spinning code can get us into a situation
where instead of going to sleep, A will spin waiting for B who is
spinning waiting for A, and the only way out of that loop is the
need_resched() test in mutex_spin_on_owner().

This patch fixes both in a rather crude way. I completely disable
spinning if we own the BKL, and I add a safety timeout using jiffies
to fallback to sleeping if we end up spinning for more than 1 or 2
jiffies.

Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: <stable@kernel.org>
---
kernel/mutex.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/kernel/mutex.c b/kernel/mutex.c
index 632f04c..c38d302 100644
--- a/kernel/mutex.c
+++ b/kernel/mutex.c
@@ -172,6 +172,13 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
struct thread_info *owner;

/*
+ * If we own the BKL, then don't spin. The owner of the mutex
+ * might be waiting on us to release the BKL.
+ */
+ if (current->lock_depth >= 0)
+ break;
+
+ /*
* If there's an owner, wait for it to either
* release the lock or go to sleep.
*/
--
1.6.6.1

Yours Tony


\
 
 \ /
  Last update: 2010-05-19 07:49    [W:2.083 / U:0.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site