mutex: Add a delay into the SPIN_ON_OWNER wait loop.

On arm systems the spin on owner optimization can intermittently cause a
lockup that's usually as long as the waiting thread's cpu timeslice. The
repeated mutex aquisitions + atomics in a single spinning thread can
completely lock out the owner from releasing the kernel mutex. The
owner needs to acquire a spinlock on the relase path and this spinlock
can share a monitor with the other locks and atomics on the waiter path.
Rate limit the waiter so that the thread releasing the mutex never
is starved.

Bug 23036902

Change-Id: Ie1b64275a0c6141f94faaf3e63fcbf9b5438140c
Signed-off-by: Riley Andrews <riandrews@google.com>
Git-commit: 84d8ce7e0025cac60a8a379a7ee3e59d640fbc03
Git-repo: https://android.googlesource.com/kernel/msm.git
Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
This commit is contained in:
Riley Andrews 2015-08-10 14:02:29 -07:00 committed by Rishabh Bhatnagar
parent 13c6da4581
commit 1e5a5b5e00

View File

@ -28,6 +28,7 @@
#include <linux/interrupt.h>
#include <linux/debug_locks.h>
#include <linux/osq_lock.h>
#include <linux/delay.h>
#ifdef CONFIG_DEBUG_MUTEXES
# include "mutex-debug.h"
@ -555,6 +556,17 @@ mutex_optimistic_spin(struct mutex *lock, struct ww_acquire_ctx *ww_ctx,
* values at the cost of a few extra spins.
*/
cpu_relax();
/*
* On arm systems, we must slow down the waiter's repeated
* aquisition of spin_mlock and atomics on the lock count, or
* we risk starving out a thread attempting to release the
* mutex. The mutex slowpath release must take spin lock
* wait_lock. This spin lock can share a monitor with the
* other waiter atomics in the mutex data structure, so must
* take care to rate limit the waiters.
*/
udelay(1);
}
if (!waiter)