Revert "mutex: Add a delay into the SPIN_ON_OWNER wait loop."
This reverts commit 1e5a5b5e00
.
This doesn't make sense for a few reasons. Firstly, upstream uses this
mutex code and it works fine on all arches; why should arm be any
different?
Secondly, once the mutex owner starts to spin on `wait_lock`,
preemption is disabled and the owner will be in an actively-running
state. The optimistic mutex spinning occurs when the lock owner is
actively running on a CPU, and while the optimistic spinning takes
place, no attempt to acquire `wait_lock` is made by the new waiter.
Therefore, it is guaranteed that new mutex waiters which optimistically
spin will not contend the `wait_lock` spin lock that the owner needs to
acquire in order to make forward progress.
Another potential source of `wait_lock` contention can come from tasks
that call mutex_trylock(), but this isn't actually problematic (and if
it were, it would affect the MUTEX_SPIN_ON_OWNER=n use-case too). This
won't introduce significant contention on `wait_lock` because the
trylock code exits before attempting to lock `wait_lock`, specifically
when the atomic mutex counter indicates that the mutex is already
locked. So in reality, the amount of `wait_lock` contention that can
come from mutex_trylock() amounts to only one task. And once it
finishes, `wait_lock` will no longer be contended and the previous
mutex owner can proceed with clean up.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
This commit is contained in:
parent
0a2139efa8
commit
73a40230d3
@ -28,7 +28,6 @@
|
||||
#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"
|
||||
@ -690,17 +689,6 @@ 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)
|
||||
|
Loading…
Reference in New Issue
Block a user