AcoSail/kernel_optimize_test
8
0
Fork 0
forked from luck/tmp_suning_uos_patched
Code Pull Requests Activity

locking/mutexes: Correct documentation on mutex optimistic spinning

Browse Source 
The mutex optimistic spinning documentation states that we spin for
acquisition when we find that there are no pending waiters. However,
in actuality, whether or not there are waiters for the mutex doesn't
determine if we will spin for it.

This patch removes that statement and also adds a comment which
mentions that we spin for the mutex while we don't need to reschedule.

Signed-off-by: Jason Low <jason.low2@hp.com>
Acked-by: Davidlohr Bueso <davidlohr@hp.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: akpm@linux-foundation.org
Cc: tim.c.chen@linux.intel.com
Cc: paulmck@linux.vnet.ibm.com
Cc: rostedt@goodmis.org
Cc: Waiman.Long@hp.com
Cc: scott.norton@hp.com
Cc: aswin@hp.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1402511843-4721-2-git-send-email-jason.low2@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Jason Low 2014-06-11 11:37:20 -07:00 committed by Ingo Molnar
parent 6cc620bc8e
commit 0c3c0f0d6e
1 changed files with 4 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
kernel/locking/mutex.c
View File

@ -388,12 +388,10 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
/* /*
* Optimistic spinning. * Optimistic spinning.
* *
* We try to spin for acquisition when we find that there are no * We try to spin for acquisition when we find that the lock owner
* pending waiters and the lock owner is currently running on a * is currently running on a (different) CPU and while we don't
* (different) CPU. * need to reschedule. The rationale is that if the lock owner is
* * running, it is likely to release the lock soon.
* The rationale is that if the lock owner is running, it is likely to
* release the lock soon.
* *
* Since this needs the lock owner, and this mutex implementation * Since this needs the lock owner, and this mutex implementation
* doesn't track the owner atomically in the lock field, we need to * doesn't track the owner atomically in the lock field, we need to