2019-05-19 20:08:55 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2006-01-10 07:59:19 +08:00
|
|
|
/*
|
2013-11-08 15:26:39 +08:00
|
|
|
* kernel/locking/mutex.c
|
2006-01-10 07:59:19 +08:00
|
|
|
*
|
|
|
|
* Mutexes: blocking mutual exclusion locks
|
|
|
|
*
|
|
|
|
* Started by Ingo Molnar:
|
|
|
|
*
|
|
|
|
* Copyright (C) 2004, 2005, 2006 Red Hat, Inc., Ingo Molnar <mingo@redhat.com>
|
|
|
|
*
|
|
|
|
* Many thanks to Arjan van de Ven, Thomas Gleixner, Steven Rostedt and
|
|
|
|
* David Howells for suggestions and improvements.
|
|
|
|
*
|
2009-01-12 21:01:47 +08:00
|
|
|
* - Adaptive spinning for mutexes by Peter Zijlstra. (Ported to mainline
|
|
|
|
* from the -rt tree, where it was originally implemented for rtmutexes
|
|
|
|
* by Steven Rostedt, based on work by Gregory Haskins, Peter Morreale
|
|
|
|
* and Sven Dietrich.
|
|
|
|
*
|
2019-04-10 19:32:41 +08:00
|
|
|
* Also see Documentation/locking/mutex-design.rst.
|
2006-01-10 07:59:19 +08:00
|
|
|
*/
|
|
|
|
#include <linux/mutex.h>
|
2013-07-05 15:29:32 +08:00
|
|
|
#include <linux/ww_mutex.h>
|
2017-02-03 02:15:33 +08:00
|
|
|
#include <linux/sched/signal.h>
|
2013-02-07 23:47:07 +08:00
|
|
|
#include <linux/sched/rt.h>
|
2017-02-01 23:36:40 +08:00
|
|
|
#include <linux/sched/wake_q.h>
|
2017-02-09 01:51:35 +08:00
|
|
|
#include <linux/sched/debug.h>
|
2011-05-24 02:51:41 +08:00
|
|
|
#include <linux/export.h>
|
2006-01-10 07:59:19 +08:00
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/interrupt.h>
|
2006-07-03 15:24:33 +08:00
|
|
|
#include <linux/debug_locks.h>
|
2015-01-30 17:14:25 +08:00
|
|
|
#include <linux/osq_lock.h>
|
2006-01-10 07:59:19 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
|
|
|
# include "mutex-debug.h"
|
|
|
|
#else
|
|
|
|
# include "mutex.h"
|
|
|
|
#endif
|
|
|
|
|
2006-07-03 15:24:55 +08:00
|
|
|
void
|
|
|
|
__mutex_init(struct mutex *lock, const char *name, struct lock_class_key *key)
|
2006-01-10 07:59:19 +08:00
|
|
|
{
|
2016-08-23 19:36:04 +08:00
|
|
|
atomic_long_set(&lock->owner, 0);
|
2006-01-10 07:59:19 +08:00
|
|
|
spin_lock_init(&lock->wait_lock);
|
|
|
|
INIT_LIST_HEAD(&lock->wait_list);
|
mutex: Queue mutex spinners with MCS lock to reduce cacheline contention
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option
turned on) allow multiple tasks to spin on a single mutex
concurrently. A potential problem with the current approach is
that when the mutex becomes available, all the spinning tasks
will try to acquire the mutex more or less simultaneously. As a
result, there will be a lot of cacheline bouncing especially on
systems with a large number of CPUs.
This patch tries to reduce this kind of contention by putting
the mutex spinners into a queue so that only the first one in
the queue will try to acquire the mutex. This will reduce
contention and allow all the tasks to move forward faster.
The queuing of mutex spinners is done using an MCS lock based
implementation which will further reduce contention on the mutex
cacheline than a similar ticket spinlock based implementation.
This patch will add a new field into the mutex data structure
for holding the MCS lock. This expands the mutex size by 8 bytes
for 64-bit system and 4 bytes for 32-bit system. This overhead
will be avoid if the MUTEX_SPIN_ON_OWNER option is turned off.
The following table shows the jobs per minute (JPM) scalability
data on an 8-node 80-core Westmere box with a 3.7.10 kernel. The
numactl command is used to restrict the running of the fserver
workloads to 1/2/4/8 nodes with hyperthreading off.
+-----------------+-----------+-----------+-------------+----------+
| Configuration | Mean JPM | Mean JPM | Mean JPM | % Change |
| | w/o patch | patch 1 | patches 1&2 | 1->1&2 |
+-----------------+------------------------------------------------+
| | User Range 1100 - 2000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 227972 | 227237 | 305043 | +34.2% |
| 4 nodes, HT off | 393503 | 381558 | 394650 | +3.4% |
| 2 nodes, HT off | 334957 | 325240 | 338853 | +4.2% |
| 1 node , HT off | 198141 | 197972 | 198075 | +0.1% |
+-----------------+------------------------------------------------+
| | User Range 200 - 1000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 282325 | 312870 | 332185 | +6.2% |
| 4 nodes, HT off | 390698 | 378279 | 393419 | +4.0% |
| 2 nodes, HT off | 336986 | 326543 | 340260 | +4.2% |
| 1 node , HT off | 197588 | 197622 | 197582 | 0.0% |
+-----------------+-----------+-----------+-------------+----------+
At low user range 10-100, the JPM differences were within +/-1%.
So they are not that interesting.
The fserver workload uses mutex spinning extensively. With just
the mutex change in the first patch, there is no noticeable
change in performance. Rather, there is a slight drop in
performance. This mutex spinning patch more than recovers the
lost performance and show a significant increase of +30% at high
user load with the full 8 nodes. Similar improvements were also
seen in a 3.8 kernel.
The table below shows the %time spent by different kernel
functions as reported by perf when running the fserver workload
at 1500 users with all 8 nodes.
+-----------------------+-----------+---------+-------------+
| Function | % time | % time | % time |
| | w/o patch | patch 1 | patches 1&2 |
+-----------------------+-----------+---------+-------------+
| __read_lock_failed | 34.96% | 34.91% | 29.14% |
| __write_lock_failed | 10.14% | 10.68% | 7.51% |
| mutex_spin_on_owner | 3.62% | 3.42% | 2.33% |
| mspin_lock | N/A | N/A | 9.90% |
| __mutex_lock_slowpath | 1.46% | 0.81% | 0.14% |
| _raw_spin_lock | 2.25% | 2.50% | 1.10% |
+-----------------------+-----------+---------+-------------+
The fserver workload for an 8-node system is dominated by the
contention in the read/write lock. Mutex contention also plays a
role. With the first patch only, mutex contention is down (as
shown by the __mutex_lock_slowpath figure) which help a little
bit. We saw only a few percents improvement with that.
By applying patch 2 as well, the single mutex_spin_on_owner
figure is now split out into an additional mspin_lock figure.
The time increases from 3.42% to 11.23%. It shows a great
reduction in contention among the spinners leading to a 30%
improvement. The time ratio 9.9/2.33=4.3 indicates that there
are on average 4+ spinners waiting in the spin_lock loop for
each spinner in the mutex_spin_on_owner loop. Contention in
other locking functions also go down by quite a lot.
The table below shows the performance change of both patches 1 &
2 over patch 1 alone in other AIM7 workloads (at 8 nodes,
hyperthreading off).
+--------------+---------------+----------------+-----------------+
| Workload | mean % change | mean % change | mean % change |
| | 10-100 users | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| alltests | 0.0% | -0.8% | +0.6% |
| five_sec | -0.3% | +0.8% | +0.8% |
| high_systime | +0.4% | +2.4% | +2.1% |
| new_fserver | +0.1% | +14.1% | +34.2% |
| shared | -0.5% | -0.3% | -0.4% |
| short | -1.7% | -9.8% | -8.3% |
+--------------+---------------+----------------+-----------------+
The short workload is the only one that shows a decline in
performance probably due to the spinner locking and queuing
overhead.
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Chandramouleeswaran Aswin <aswin@hp.com>
Cc: Norton Scott J <scott.norton@hp.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1366226594-5506-4-git-send-email-Waiman.Long@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-04-18 03:23:13 +08:00
|
|
|
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
|
2014-07-15 01:27:50 +08:00
|
|
|
osq_lock_init(&lock->osq);
|
mutex: Queue mutex spinners with MCS lock to reduce cacheline contention
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option
turned on) allow multiple tasks to spin on a single mutex
concurrently. A potential problem with the current approach is
that when the mutex becomes available, all the spinning tasks
will try to acquire the mutex more or less simultaneously. As a
result, there will be a lot of cacheline bouncing especially on
systems with a large number of CPUs.
This patch tries to reduce this kind of contention by putting
the mutex spinners into a queue so that only the first one in
the queue will try to acquire the mutex. This will reduce
contention and allow all the tasks to move forward faster.
The queuing of mutex spinners is done using an MCS lock based
implementation which will further reduce contention on the mutex
cacheline than a similar ticket spinlock based implementation.
This patch will add a new field into the mutex data structure
for holding the MCS lock. This expands the mutex size by 8 bytes
for 64-bit system and 4 bytes for 32-bit system. This overhead
will be avoid if the MUTEX_SPIN_ON_OWNER option is turned off.
The following table shows the jobs per minute (JPM) scalability
data on an 8-node 80-core Westmere box with a 3.7.10 kernel. The
numactl command is used to restrict the running of the fserver
workloads to 1/2/4/8 nodes with hyperthreading off.
+-----------------+-----------+-----------+-------------+----------+
| Configuration | Mean JPM | Mean JPM | Mean JPM | % Change |
| | w/o patch | patch 1 | patches 1&2 | 1->1&2 |
+-----------------+------------------------------------------------+
| | User Range 1100 - 2000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 227972 | 227237 | 305043 | +34.2% |
| 4 nodes, HT off | 393503 | 381558 | 394650 | +3.4% |
| 2 nodes, HT off | 334957 | 325240 | 338853 | +4.2% |
| 1 node , HT off | 198141 | 197972 | 198075 | +0.1% |
+-----------------+------------------------------------------------+
| | User Range 200 - 1000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 282325 | 312870 | 332185 | +6.2% |
| 4 nodes, HT off | 390698 | 378279 | 393419 | +4.0% |
| 2 nodes, HT off | 336986 | 326543 | 340260 | +4.2% |
| 1 node , HT off | 197588 | 197622 | 197582 | 0.0% |
+-----------------+-----------+-----------+-------------+----------+
At low user range 10-100, the JPM differences were within +/-1%.
So they are not that interesting.
The fserver workload uses mutex spinning extensively. With just
the mutex change in the first patch, there is no noticeable
change in performance. Rather, there is a slight drop in
performance. This mutex spinning patch more than recovers the
lost performance and show a significant increase of +30% at high
user load with the full 8 nodes. Similar improvements were also
seen in a 3.8 kernel.
The table below shows the %time spent by different kernel
functions as reported by perf when running the fserver workload
at 1500 users with all 8 nodes.
+-----------------------+-----------+---------+-------------+
| Function | % time | % time | % time |
| | w/o patch | patch 1 | patches 1&2 |
+-----------------------+-----------+---------+-------------+
| __read_lock_failed | 34.96% | 34.91% | 29.14% |
| __write_lock_failed | 10.14% | 10.68% | 7.51% |
| mutex_spin_on_owner | 3.62% | 3.42% | 2.33% |
| mspin_lock | N/A | N/A | 9.90% |
| __mutex_lock_slowpath | 1.46% | 0.81% | 0.14% |
| _raw_spin_lock | 2.25% | 2.50% | 1.10% |
+-----------------------+-----------+---------+-------------+
The fserver workload for an 8-node system is dominated by the
contention in the read/write lock. Mutex contention also plays a
role. With the first patch only, mutex contention is down (as
shown by the __mutex_lock_slowpath figure) which help a little
bit. We saw only a few percents improvement with that.
By applying patch 2 as well, the single mutex_spin_on_owner
figure is now split out into an additional mspin_lock figure.
The time increases from 3.42% to 11.23%. It shows a great
reduction in contention among the spinners leading to a 30%
improvement. The time ratio 9.9/2.33=4.3 indicates that there
are on average 4+ spinners waiting in the spin_lock loop for
each spinner in the mutex_spin_on_owner loop. Contention in
other locking functions also go down by quite a lot.
The table below shows the performance change of both patches 1 &
2 over patch 1 alone in other AIM7 workloads (at 8 nodes,
hyperthreading off).
+--------------+---------------+----------------+-----------------+
| Workload | mean % change | mean % change | mean % change |
| | 10-100 users | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| alltests | 0.0% | -0.8% | +0.6% |
| five_sec | -0.3% | +0.8% | +0.8% |
| high_systime | +0.4% | +2.4% | +2.1% |
| new_fserver | +0.1% | +14.1% | +34.2% |
| shared | -0.5% | -0.3% | -0.4% |
| short | -1.7% | -9.8% | -8.3% |
+--------------+---------------+----------------+-----------------+
The short workload is the only one that shows a decline in
performance probably due to the spinner locking and queuing
overhead.
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Chandramouleeswaran Aswin <aswin@hp.com>
Cc: Norton Scott J <scott.norton@hp.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1366226594-5506-4-git-send-email-Waiman.Long@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-04-18 03:23:13 +08:00
|
|
|
#endif
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2006-07-03 15:24:55 +08:00
|
|
|
debug_mutex_init(lock, name, key);
|
2006-01-10 07:59:19 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__mutex_init);
|
|
|
|
|
2016-08-23 19:36:04 +08:00
|
|
|
/*
|
|
|
|
* @owner: contains: 'struct task_struct *' to the current lock owner,
|
|
|
|
* NULL means not owned. Since task_struct pointers are aligned at
|
2017-01-11 21:17:48 +08:00
|
|
|
* at least L1_CACHE_BYTES, we have low bits to store extra state.
|
2016-08-23 19:36:04 +08:00
|
|
|
*
|
|
|
|
* Bit0 indicates a non-empty waiter list; unlock must issue a wakeup.
|
2016-08-23 20:40:16 +08:00
|
|
|
* Bit1 indicates unlock needs to hand the lock to the top-waiter
|
2017-01-11 21:17:48 +08:00
|
|
|
* Bit2 indicates handoff has been done and we're waiting for pickup.
|
2016-08-23 19:36:04 +08:00
|
|
|
*/
|
|
|
|
#define MUTEX_FLAG_WAITERS 0x01
|
2016-08-23 20:40:16 +08:00
|
|
|
#define MUTEX_FLAG_HANDOFF 0x02
|
2017-01-11 21:17:48 +08:00
|
|
|
#define MUTEX_FLAG_PICKUP 0x04
|
2016-08-23 19:36:04 +08:00
|
|
|
|
2017-01-11 21:17:48 +08:00
|
|
|
#define MUTEX_FLAGS 0x07
|
2016-08-23 19:36:04 +08:00
|
|
|
|
2019-07-31 23:05:03 +08:00
|
|
|
/*
|
|
|
|
* Internal helper function; C doesn't allow us to hide it :/
|
|
|
|
*
|
|
|
|
* DO NOT USE (outside of mutex code).
|
|
|
|
*/
|
|
|
|
static inline struct task_struct *__mutex_owner(struct mutex *lock)
|
|
|
|
{
|
2019-07-31 23:05:04 +08:00
|
|
|
return (struct task_struct *)(atomic_long_read(&lock->owner) & ~MUTEX_FLAGS);
|
2019-07-31 23:05:03 +08:00
|
|
|
}
|
|
|
|
|
2016-08-23 19:36:04 +08:00
|
|
|
static inline struct task_struct *__owner_task(unsigned long owner)
|
|
|
|
{
|
|
|
|
return (struct task_struct *)(owner & ~MUTEX_FLAGS);
|
|
|
|
}
|
|
|
|
|
2019-07-31 23:05:03 +08:00
|
|
|
bool mutex_is_locked(struct mutex *lock)
|
|
|
|
{
|
|
|
|
return __mutex_owner(lock) != NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mutex_is_locked);
|
|
|
|
|
|
|
|
__must_check enum mutex_trylock_recursive_enum
|
|
|
|
mutex_trylock_recursive(struct mutex *lock)
|
|
|
|
{
|
|
|
|
if (unlikely(__mutex_owner(lock) == current))
|
|
|
|
return MUTEX_TRYLOCK_RECURSIVE;
|
|
|
|
|
|
|
|
return mutex_trylock(lock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mutex_trylock_recursive);
|
|
|
|
|
2016-08-23 19:36:04 +08:00
|
|
|
static inline unsigned long __owner_flags(unsigned long owner)
|
|
|
|
{
|
|
|
|
return owner & MUTEX_FLAGS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-01-11 21:17:48 +08:00
|
|
|
* Trylock variant that retuns the owning task on failure.
|
2016-08-23 19:36:04 +08:00
|
|
|
*/
|
2017-01-11 21:17:48 +08:00
|
|
|
static inline struct task_struct *__mutex_trylock_or_owner(struct mutex *lock)
|
2016-08-23 19:36:04 +08:00
|
|
|
{
|
|
|
|
unsigned long owner, curr = (unsigned long)current;
|
|
|
|
|
|
|
|
owner = atomic_long_read(&lock->owner);
|
|
|
|
for (;;) { /* must loop, can race against a flag */
|
2016-08-23 20:40:16 +08:00
|
|
|
unsigned long old, flags = __owner_flags(owner);
|
2017-01-11 21:17:48 +08:00
|
|
|
unsigned long task = owner & ~MUTEX_FLAGS;
|
2016-08-23 20:40:16 +08:00
|
|
|
|
2017-01-11 21:17:48 +08:00
|
|
|
if (task) {
|
|
|
|
if (likely(task != curr))
|
|
|
|
break;
|
2016-08-23 19:36:04 +08:00
|
|
|
|
2017-01-11 21:17:48 +08:00
|
|
|
if (likely(!(flags & MUTEX_FLAG_PICKUP)))
|
|
|
|
break;
|
2016-08-23 20:40:16 +08:00
|
|
|
|
2017-01-11 21:17:48 +08:00
|
|
|
flags &= ~MUTEX_FLAG_PICKUP;
|
|
|
|
} else {
|
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
|
|
|
DEBUG_LOCKS_WARN_ON(flags & MUTEX_FLAG_PICKUP);
|
|
|
|
#endif
|
2016-08-23 20:40:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We set the HANDOFF bit, we must make sure it doesn't live
|
|
|
|
* past the point where we acquire it. This would be possible
|
|
|
|
* if we (accidentally) set the bit on an unlocked mutex.
|
|
|
|
*/
|
2017-01-11 21:17:48 +08:00
|
|
|
flags &= ~MUTEX_FLAG_HANDOFF;
|
2016-08-23 19:36:04 +08:00
|
|
|
|
2016-08-23 20:40:16 +08:00
|
|
|
old = atomic_long_cmpxchg_acquire(&lock->owner, owner, curr | flags);
|
2016-08-23 19:36:04 +08:00
|
|
|
if (old == owner)
|
2017-01-11 21:17:48 +08:00
|
|
|
return NULL;
|
2016-08-23 19:36:04 +08:00
|
|
|
|
|
|
|
owner = old;
|
|
|
|
}
|
2017-01-11 21:17:48 +08:00
|
|
|
|
|
|
|
return __owner_task(owner);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Actual trylock that will work on any unlocked state.
|
|
|
|
*/
|
|
|
|
static inline bool __mutex_trylock(struct mutex *lock)
|
|
|
|
{
|
|
|
|
return !__mutex_trylock_or_owner(lock);
|
2016-08-23 19:36:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifndef CONFIG_DEBUG_LOCK_ALLOC
|
|
|
|
/*
|
|
|
|
* Lockdep annotations are contained to the slow paths for simplicity.
|
|
|
|
* There is nothing that would stop spreading the lockdep annotations outwards
|
|
|
|
* except more code.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Optimistic trylock that only works in the uncontended case. Make sure to
|
|
|
|
* follow with a __mutex_trylock() before failing.
|
|
|
|
*/
|
|
|
|
static __always_inline bool __mutex_trylock_fast(struct mutex *lock)
|
|
|
|
{
|
|
|
|
unsigned long curr = (unsigned long)current;
|
locking/mutex: Optimize __mutex_trylock_fast()
Use try_cmpxchg to avoid the pointless TEST instruction..
And add the (missing) atomic_long_try_cmpxchg*() wrappery.
On x86_64 this gives:
0000000000000710 <mutex_lock>: 0000000000000710 <mutex_lock>:
710: 65 48 8b 14 25 00 00 mov %gs:0x0,%rdx 710: 65 48 8b 14 25 00 00 mov %gs:0x0,%rdx
717: 00 00 717: 00 00
715: R_X86_64_32S current_task 715: R_X86_64_32S current_task
719: 31 c0 xor %eax,%eax 719: 31 c0 xor %eax,%eax
71b: f0 48 0f b1 17 lock cmpxchg %rdx,(%rdi) 71b: f0 48 0f b1 17 lock cmpxchg %rdx,(%rdi)
720: 48 85 c0 test %rax,%rax 720: 75 02 jne 724 <mutex_lock+0x14>
723: 75 02 jne 727 <mutex_lock+0x17> 722: f3 c3 repz retq
725: f3 c3 repz retq 724: eb da jmp 700 <__mutex_lock_slowpath>
727: eb d7 jmp 700 <__mutex_lock_slowpath> 726: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
729: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 72d: 00 00 00
On ARM64 this gives:
000000000000638 <mutex_lock>: 0000000000000638 <mutex_lock>:
638: d5384101 mrs x1, sp_el0 638: d5384101 mrs x1, sp_el0
63c: d2800002 mov x2, #0x0 63c: d2800002 mov x2, #0x0
640: f9800011 prfm pstl1strm, [x0] 640: f9800011 prfm pstl1strm, [x0]
644: c85ffc03 ldaxr x3, [x0] 644: c85ffc03 ldaxr x3, [x0]
648: ca020064 eor x4, x3, x2 648: ca020064 eor x4, x3, x2
64c: b5000064 cbnz x4, 658 <mutex_lock+0x20> 64c: b5000064 cbnz x4, 658 <mutex_lock+0x20>
650: c8047c01 stxr w4, x1, [x0] 650: c8047c01 stxr w4, x1, [x0]
654: 35ffff84 cbnz w4, 644 <mutex_lock+0xc> 654: 35ffff84 cbnz w4, 644 <mutex_lock+0xc>
658: b40000c3 cbz x3, 670 <mutex_lock+0x38> 658: b5000043 cbnz x3, 660 <mutex_lock+0x28>
65c: a9bf7bfd stp x29, x30, [sp,#-16]! 65c: d65f03c0 ret
660: 910003fd mov x29, sp 660: a9bf7bfd stp x29, x30, [sp,#-16]!
664: 97ffffef bl 620 <__mutex_lock_slowpath> 664: 910003fd mov x29, sp
668: a8c17bfd ldp x29, x30, [sp],#16 668: 97ffffee bl 620 <__mutex_lock_slowpath>
66c: d65f03c0 ret 66c: a8c17bfd ldp x29, x30, [sp],#16
670: d65f03c0 ret 670: d65f03c0 ret
Reported-by: Matthew Wilcox <mawilcox@microsoft.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-05 17:05:35 +08:00
|
|
|
unsigned long zero = 0UL;
|
2016-08-23 19:36:04 +08:00
|
|
|
|
locking/mutex: Optimize __mutex_trylock_fast()
Use try_cmpxchg to avoid the pointless TEST instruction..
And add the (missing) atomic_long_try_cmpxchg*() wrappery.
On x86_64 this gives:
0000000000000710 <mutex_lock>: 0000000000000710 <mutex_lock>:
710: 65 48 8b 14 25 00 00 mov %gs:0x0,%rdx 710: 65 48 8b 14 25 00 00 mov %gs:0x0,%rdx
717: 00 00 717: 00 00
715: R_X86_64_32S current_task 715: R_X86_64_32S current_task
719: 31 c0 xor %eax,%eax 719: 31 c0 xor %eax,%eax
71b: f0 48 0f b1 17 lock cmpxchg %rdx,(%rdi) 71b: f0 48 0f b1 17 lock cmpxchg %rdx,(%rdi)
720: 48 85 c0 test %rax,%rax 720: 75 02 jne 724 <mutex_lock+0x14>
723: 75 02 jne 727 <mutex_lock+0x17> 722: f3 c3 repz retq
725: f3 c3 repz retq 724: eb da jmp 700 <__mutex_lock_slowpath>
727: eb d7 jmp 700 <__mutex_lock_slowpath> 726: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
729: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 72d: 00 00 00
On ARM64 this gives:
000000000000638 <mutex_lock>: 0000000000000638 <mutex_lock>:
638: d5384101 mrs x1, sp_el0 638: d5384101 mrs x1, sp_el0
63c: d2800002 mov x2, #0x0 63c: d2800002 mov x2, #0x0
640: f9800011 prfm pstl1strm, [x0] 640: f9800011 prfm pstl1strm, [x0]
644: c85ffc03 ldaxr x3, [x0] 644: c85ffc03 ldaxr x3, [x0]
648: ca020064 eor x4, x3, x2 648: ca020064 eor x4, x3, x2
64c: b5000064 cbnz x4, 658 <mutex_lock+0x20> 64c: b5000064 cbnz x4, 658 <mutex_lock+0x20>
650: c8047c01 stxr w4, x1, [x0] 650: c8047c01 stxr w4, x1, [x0]
654: 35ffff84 cbnz w4, 644 <mutex_lock+0xc> 654: 35ffff84 cbnz w4, 644 <mutex_lock+0xc>
658: b40000c3 cbz x3, 670 <mutex_lock+0x38> 658: b5000043 cbnz x3, 660 <mutex_lock+0x28>
65c: a9bf7bfd stp x29, x30, [sp,#-16]! 65c: d65f03c0 ret
660: 910003fd mov x29, sp 660: a9bf7bfd stp x29, x30, [sp,#-16]!
664: 97ffffef bl 620 <__mutex_lock_slowpath> 664: 910003fd mov x29, sp
668: a8c17bfd ldp x29, x30, [sp],#16 668: 97ffffee bl 620 <__mutex_lock_slowpath>
66c: d65f03c0 ret 66c: a8c17bfd ldp x29, x30, [sp],#16
670: d65f03c0 ret 670: d65f03c0 ret
Reported-by: Matthew Wilcox <mawilcox@microsoft.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-05 17:05:35 +08:00
|
|
|
if (atomic_long_try_cmpxchg_acquire(&lock->owner, &zero, curr))
|
2016-08-23 19:36:04 +08:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static __always_inline bool __mutex_unlock_fast(struct mutex *lock)
|
|
|
|
{
|
|
|
|
unsigned long curr = (unsigned long)current;
|
|
|
|
|
|
|
|
if (atomic_long_cmpxchg_release(&lock->owner, curr, 0UL) == curr)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static inline void __mutex_set_flag(struct mutex *lock, unsigned long flag)
|
|
|
|
{
|
|
|
|
atomic_long_or(flag, &lock->owner);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void __mutex_clear_flag(struct mutex *lock, unsigned long flag)
|
|
|
|
{
|
|
|
|
atomic_long_andnot(flag, &lock->owner);
|
|
|
|
}
|
|
|
|
|
2016-08-23 20:40:16 +08:00
|
|
|
static inline bool __mutex_waiter_is_first(struct mutex *lock, struct mutex_waiter *waiter)
|
|
|
|
{
|
|
|
|
return list_first_entry(&lock->wait_list, struct mutex_waiter, list) == waiter;
|
|
|
|
}
|
|
|
|
|
2018-06-15 16:17:38 +08:00
|
|
|
/*
|
|
|
|
* Add @waiter to a given location in the lock wait_list and set the
|
|
|
|
* FLAG_WAITERS flag if it's the first waiter.
|
|
|
|
*/
|
2024-06-12 13:13:20 +08:00
|
|
|
static void
|
2018-06-15 16:17:38 +08:00
|
|
|
__mutex_add_waiter(struct mutex *lock, struct mutex_waiter *waiter,
|
|
|
|
struct list_head *list)
|
|
|
|
{
|
|
|
|
debug_mutex_add_waiter(lock, waiter, current);
|
|
|
|
|
|
|
|
list_add_tail(&waiter->list, list);
|
|
|
|
if (__mutex_waiter_is_first(lock, waiter))
|
|
|
|
__mutex_set_flag(lock, MUTEX_FLAG_WAITERS);
|
|
|
|
}
|
|
|
|
|
2024-06-12 13:13:20 +08:00
|
|
|
static void
|
|
|
|
__mutex_remove_waiter(struct mutex *lock, struct mutex_waiter *waiter)
|
|
|
|
{
|
|
|
|
list_del(&waiter->list);
|
|
|
|
if (likely(list_empty(&lock->wait_list)))
|
|
|
|
__mutex_clear_flag(lock, MUTEX_FLAGS);
|
|
|
|
|
|
|
|
debug_mutex_remove_waiter(lock, waiter, current);
|
|
|
|
}
|
|
|
|
|
2016-08-23 20:40:16 +08:00
|
|
|
/*
|
|
|
|
* Give up ownership to a specific task, when @task = NULL, this is equivalent
|
2017-01-11 21:17:48 +08:00
|
|
|
* to a regular unlock. Sets PICKUP on a handoff, clears HANDOF, preserves
|
|
|
|
* WAITERS. Provides RELEASE semantics like a regular unlock, the
|
|
|
|
* __mutex_trylock() provides a matching ACQUIRE semantics for the handoff.
|
2016-08-23 20:40:16 +08:00
|
|
|
*/
|
|
|
|
static void __mutex_handoff(struct mutex *lock, struct task_struct *task)
|
|
|
|
{
|
|
|
|
unsigned long owner = atomic_long_read(&lock->owner);
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
unsigned long old, new;
|
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
|
|
|
DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current);
|
2017-01-11 21:17:48 +08:00
|
|
|
DEBUG_LOCKS_WARN_ON(owner & MUTEX_FLAG_PICKUP);
|
2016-08-23 20:40:16 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
new = (owner & MUTEX_FLAG_WAITERS);
|
|
|
|
new |= (unsigned long)task;
|
2017-01-11 21:17:48 +08:00
|
|
|
if (task)
|
|
|
|
new |= MUTEX_FLAG_PICKUP;
|
2016-08-23 20:40:16 +08:00
|
|
|
|
|
|
|
old = atomic_long_cmpxchg_release(&lock->owner, owner, new);
|
|
|
|
if (old == owner)
|
|
|
|
break;
|
|
|
|
|
|
|
|
owner = old;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-10-12 04:11:12 +08:00
|
|
|
#ifndef CONFIG_DEBUG_LOCK_ALLOC
|
2006-01-10 07:59:19 +08:00
|
|
|
/*
|
|
|
|
* We split the mutex lock/unlock logic into separate fastpath and
|
|
|
|
* slowpath functions, to reduce the register pressure on the fastpath.
|
|
|
|
* We also put the fastpath first in the kernel image, to make sure the
|
|
|
|
* branch is predicted by the CPU as default-untaken.
|
|
|
|
*/
|
2016-08-23 19:36:04 +08:00
|
|
|
static void __sched __mutex_lock_slowpath(struct mutex *lock);
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2010-09-03 06:48:16 +08:00
|
|
|
/**
|
2006-01-10 07:59:19 +08:00
|
|
|
* mutex_lock - acquire the mutex
|
|
|
|
* @lock: the mutex to be acquired
|
|
|
|
*
|
|
|
|
* Lock the mutex exclusively for this task. If the mutex is not
|
|
|
|
* available right now, it will sleep until it can get it.
|
|
|
|
*
|
|
|
|
* The mutex must later on be released by the same task that
|
|
|
|
* acquired it. Recursive locking is not allowed. The task
|
|
|
|
* may not exit without first unlocking the mutex. Also, kernel
|
2015-02-02 05:47:32 +08:00
|
|
|
* memory where the mutex resides must not be freed with
|
2006-01-10 07:59:19 +08:00
|
|
|
* the mutex still locked. The mutex must first be initialized
|
|
|
|
* (or statically defined) before it can be locked. memset()-ing
|
|
|
|
* the mutex to 0 is not allowed.
|
|
|
|
*
|
2017-05-11 21:17:45 +08:00
|
|
|
* (The CONFIG_DEBUG_MUTEXES .config option turns on debugging
|
|
|
|
* checks that will enforce the restrictions and will also do
|
|
|
|
* deadlock debugging)
|
2006-01-10 07:59:19 +08:00
|
|
|
*
|
|
|
|
* This function is similar to (but not equivalent to) down().
|
|
|
|
*/
|
2009-04-02 08:21:56 +08:00
|
|
|
void __sched mutex_lock(struct mutex *lock)
|
2006-01-10 07:59:19 +08:00
|
|
|
{
|
2006-01-11 05:10:36 +08:00
|
|
|
might_sleep();
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2016-08-23 19:36:04 +08:00
|
|
|
if (!__mutex_trylock_fast(lock))
|
|
|
|
__mutex_lock_slowpath(lock);
|
|
|
|
}
|
2006-01-10 07:59:19 +08:00
|
|
|
EXPORT_SYMBOL(mutex_lock);
|
2007-10-12 04:11:12 +08:00
|
|
|
#endif
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2018-06-15 16:07:12 +08:00
|
|
|
/*
|
|
|
|
* Wait-Die:
|
|
|
|
* The newer transactions are killed when:
|
|
|
|
* It (the new transaction) makes a request for a lock being held
|
|
|
|
* by an older transaction.
|
2018-06-15 16:17:38 +08:00
|
|
|
*
|
|
|
|
* Wound-Wait:
|
|
|
|
* The newer transactions are wounded when:
|
|
|
|
* An older transaction makes a request for a lock being held by
|
|
|
|
* the newer transaction.
|
2018-06-15 16:07:12 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Associate the ww_mutex @ww with the context @ww_ctx under which we acquired
|
|
|
|
* it.
|
|
|
|
*/
|
2016-12-23 17:36:00 +08:00
|
|
|
static __always_inline void
|
|
|
|
ww_mutex_lock_acquired(struct ww_mutex *ww, struct ww_acquire_ctx *ww_ctx)
|
2014-07-31 04:41:53 +08:00
|
|
|
{
|
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
|
|
|
/*
|
|
|
|
* If this WARN_ON triggers, you used ww_mutex_lock to acquire,
|
|
|
|
* but released with a normal mutex_unlock in this call.
|
|
|
|
*
|
|
|
|
* This should never happen, always use ww_mutex_unlock.
|
|
|
|
*/
|
|
|
|
DEBUG_LOCKS_WARN_ON(ww->ctx);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Not quite done after calling ww_acquire_done() ?
|
|
|
|
*/
|
|
|
|
DEBUG_LOCKS_WARN_ON(ww_ctx->done_acquire);
|
|
|
|
|
|
|
|
if (ww_ctx->contending_lock) {
|
|
|
|
/*
|
|
|
|
* After -EDEADLK you tried to
|
|
|
|
* acquire a different ww_mutex? Bad!
|
|
|
|
*/
|
|
|
|
DEBUG_LOCKS_WARN_ON(ww_ctx->contending_lock != ww);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* You called ww_mutex_lock after receiving -EDEADLK,
|
|
|
|
* but 'forgot' to unlock everything else first?
|
|
|
|
*/
|
|
|
|
DEBUG_LOCKS_WARN_ON(ww_ctx->acquired > 0);
|
|
|
|
ww_ctx->contending_lock = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Naughty, using a different class will lead to undefined behavior!
|
|
|
|
*/
|
|
|
|
DEBUG_LOCKS_WARN_ON(ww_ctx->ww_class != ww->ww_class);
|
|
|
|
#endif
|
|
|
|
ww_ctx->acquired++;
|
2018-06-15 16:07:12 +08:00
|
|
|
ww->ctx = ww_ctx;
|
2014-07-31 04:41:53 +08:00
|
|
|
}
|
|
|
|
|
2018-06-15 16:07:12 +08:00
|
|
|
/*
|
|
|
|
* Determine if context @a is 'after' context @b. IOW, @a is a younger
|
|
|
|
* transaction than @b and depending on algorithm either needs to wait for
|
|
|
|
* @b or die.
|
|
|
|
*/
|
2016-12-22 02:46:31 +08:00
|
|
|
static inline bool __sched
|
|
|
|
__ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b)
|
|
|
|
{
|
2018-06-15 16:07:12 +08:00
|
|
|
|
|
|
|
return (signed long)(a->stamp - b->stamp) > 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wait-Die; wake a younger waiter context (when locks held) such that it can
|
|
|
|
* die.
|
|
|
|
*
|
|
|
|
* Among waiters with context, only the first one can have other locks acquired
|
|
|
|
* already (ctx->acquired > 0), because __ww_mutex_add_waiter() and
|
|
|
|
* __ww_mutex_check_kill() wake any but the earliest context.
|
|
|
|
*/
|
|
|
|
static bool __sched
|
|
|
|
__ww_mutex_die(struct mutex *lock, struct mutex_waiter *waiter,
|
|
|
|
struct ww_acquire_ctx *ww_ctx)
|
|
|
|
{
|
2018-06-15 16:17:38 +08:00
|
|
|
if (!ww_ctx->is_wait_die)
|
|
|
|
return false;
|
|
|
|
|
2018-06-15 16:07:12 +08:00
|
|
|
if (waiter->ww_ctx->acquired > 0 &&
|
|
|
|
__ww_ctx_stamp_after(waiter->ww_ctx, ww_ctx)) {
|
|
|
|
debug_mutex_wake_waiter(lock, waiter);
|
|
|
|
wake_up_process(waiter->task);
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
2016-12-22 02:46:31 +08:00
|
|
|
}
|
|
|
|
|
2018-06-15 16:17:38 +08:00
|
|
|
/*
|
|
|
|
* Wound-Wait; wound a younger @hold_ctx if it holds the lock.
|
|
|
|
*
|
|
|
|
* Wound the lock holder if there are waiters with older transactions than
|
|
|
|
* the lock holders. Even if multiple waiters may wound the lock holder,
|
|
|
|
* it's sufficient that only one does.
|
|
|
|
*/
|
|
|
|
static bool __ww_mutex_wound(struct mutex *lock,
|
|
|
|
struct ww_acquire_ctx *ww_ctx,
|
|
|
|
struct ww_acquire_ctx *hold_ctx)
|
|
|
|
{
|
|
|
|
struct task_struct *owner = __mutex_owner(lock);
|
|
|
|
|
|
|
|
lockdep_assert_held(&lock->wait_lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Possible through __ww_mutex_add_waiter() when we race with
|
|
|
|
* ww_mutex_set_context_fastpath(). In that case we'll get here again
|
|
|
|
* through __ww_mutex_check_waiters().
|
|
|
|
*/
|
|
|
|
if (!hold_ctx)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Can have !owner because of __mutex_unlock_slowpath(), but if owner,
|
|
|
|
* it cannot go away because we'll have FLAG_WAITERS set and hold
|
|
|
|
* wait_lock.
|
|
|
|
*/
|
|
|
|
if (!owner)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (ww_ctx->acquired > 0 && __ww_ctx_stamp_after(hold_ctx, ww_ctx)) {
|
|
|
|
hold_ctx->wounded = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* wake_up_process() paired with set_current_state()
|
|
|
|
* inserts sufficient barriers to make sure @owner either sees
|
2018-09-03 22:07:08 +08:00
|
|
|
* it's wounded in __ww_mutex_check_kill() or has a
|
2018-06-15 16:17:38 +08:00
|
|
|
* wakeup pending to re-read the wounded state.
|
|
|
|
*/
|
|
|
|
if (owner != current)
|
|
|
|
wake_up_process(owner);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-12-22 02:46:36 +08:00
|
|
|
/*
|
2018-06-15 16:07:12 +08:00
|
|
|
* We just acquired @lock under @ww_ctx, if there are later contexts waiting
|
2018-06-15 16:17:38 +08:00
|
|
|
* behind us on the wait-list, check if they need to die, or wound us.
|
2016-12-22 02:46:36 +08:00
|
|
|
*
|
2018-06-15 16:07:12 +08:00
|
|
|
* See __ww_mutex_add_waiter() for the list-order construction; basically the
|
|
|
|
* list is ordered by stamp, smallest (oldest) first.
|
2016-12-22 02:46:36 +08:00
|
|
|
*
|
2018-06-15 16:17:38 +08:00
|
|
|
* This relies on never mixing wait-die/wound-wait on the same wait-list;
|
|
|
|
* which is currently ensured by that being a ww_class property.
|
|
|
|
*
|
2016-12-22 02:46:36 +08:00
|
|
|
* The current task must not be on the wait list.
|
|
|
|
*/
|
|
|
|
static void __sched
|
2018-06-15 16:07:12 +08:00
|
|
|
__ww_mutex_check_waiters(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
|
2016-12-22 02:46:36 +08:00
|
|
|
{
|
|
|
|
struct mutex_waiter *cur;
|
|
|
|
|
|
|
|
lockdep_assert_held(&lock->wait_lock);
|
|
|
|
|
|
|
|
list_for_each_entry(cur, &lock->wait_list, list) {
|
|
|
|
if (!cur->ww_ctx)
|
|
|
|
continue;
|
|
|
|
|
2018-06-15 16:17:38 +08:00
|
|
|
if (__ww_mutex_die(lock, cur, ww_ctx) ||
|
|
|
|
__ww_mutex_wound(lock, cur->ww_ctx, ww_ctx))
|
2018-06-15 16:07:12 +08:00
|
|
|
break;
|
2016-12-22 02:46:36 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-07-31 04:41:53 +08:00
|
|
|
/*
|
2018-06-15 16:07:12 +08:00
|
|
|
* After acquiring lock with fastpath, where we do not hold wait_lock, set ctx
|
|
|
|
* and wake up any waiters so they can recheck.
|
2014-07-31 04:41:53 +08:00
|
|
|
*/
|
|
|
|
static __always_inline void
|
2016-12-23 17:36:00 +08:00
|
|
|
ww_mutex_set_context_fastpath(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
|
2014-07-31 04:41:53 +08:00
|
|
|
{
|
|
|
|
ww_mutex_lock_acquired(lock, ctx);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The lock->ctx update should be visible on all cores before
|
2018-06-15 16:07:12 +08:00
|
|
|
* the WAITERS check is done, otherwise contended waiters might be
|
2014-07-31 04:41:53 +08:00
|
|
|
* missed. The contended waiters will either see ww_ctx == NULL
|
|
|
|
* and keep spinning, or it will acquire wait_lock, add itself
|
|
|
|
* to waiter list and sleep.
|
|
|
|
*/
|
2018-06-15 16:17:38 +08:00
|
|
|
smp_mb(); /* See comments above and below. */
|
2014-07-31 04:41:53 +08:00
|
|
|
|
|
|
|
/*
|
2018-06-15 16:17:38 +08:00
|
|
|
* [W] ww->ctx = ctx [W] MUTEX_FLAG_WAITERS
|
|
|
|
* MB MB
|
|
|
|
* [R] MUTEX_FLAG_WAITERS [R] ww->ctx
|
|
|
|
*
|
|
|
|
* The memory barrier above pairs with the memory barrier in
|
|
|
|
* __ww_mutex_add_waiter() and makes sure we either observe ww->ctx
|
|
|
|
* and/or !empty list.
|
2014-07-31 04:41:53 +08:00
|
|
|
*/
|
2016-08-23 19:36:04 +08:00
|
|
|
if (likely(!(atomic_long_read(&lock->base.owner) & MUTEX_FLAG_WAITERS)))
|
2014-07-31 04:41:53 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
2018-06-15 16:07:12 +08:00
|
|
|
* Uh oh, we raced in fastpath, check if any of the waiters need to
|
2018-06-15 16:17:38 +08:00
|
|
|
* die or wound us.
|
2014-07-31 04:41:53 +08:00
|
|
|
*/
|
2017-01-17 23:06:09 +08:00
|
|
|
spin_lock(&lock->base.wait_lock);
|
2018-06-15 16:07:12 +08:00
|
|
|
__ww_mutex_check_waiters(&lock->base, ctx);
|
2017-01-17 23:06:09 +08:00
|
|
|
spin_unlock(&lock->base.wait_lock);
|
2014-07-31 04:41:53 +08:00
|
|
|
}
|
|
|
|
|
2013-04-18 03:23:11 +08:00
|
|
|
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
|
2016-12-22 02:46:38 +08:00
|
|
|
|
|
|
|
static inline
|
|
|
|
bool ww_mutex_spin_on_owner(struct mutex *lock, struct ww_acquire_ctx *ww_ctx,
|
|
|
|
struct mutex_waiter *waiter)
|
|
|
|
{
|
|
|
|
struct ww_mutex *ww;
|
|
|
|
|
|
|
|
ww = container_of(lock, struct ww_mutex, base);
|
2015-01-07 03:45:06 +08:00
|
|
|
|
|
|
|
/*
|
2016-12-22 02:46:38 +08:00
|
|
|
* If ww->ctx is set the contents are undefined, only
|
|
|
|
* by acquiring wait_lock there is a guarantee that
|
|
|
|
* they are not invalid when reading.
|
|
|
|
*
|
|
|
|
* As such, when deadlock detection needs to be
|
|
|
|
* performed the optimistic spinning cannot be done.
|
|
|
|
*
|
|
|
|
* Check this in every inner iteration because we may
|
|
|
|
* be racing against another thread's ww_mutex_lock.
|
2015-01-07 03:45:06 +08:00
|
|
|
*/
|
2016-12-22 02:46:38 +08:00
|
|
|
if (ww_ctx->acquired > 0 && READ_ONCE(ww->ctx))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we aren't on the wait list yet, cancel the spin
|
|
|
|
* if there are waiters. We want to avoid stealing the
|
|
|
|
* lock from a waiter with an earlier stamp, since the
|
|
|
|
* other thread may already own a lock that we also
|
|
|
|
* need.
|
|
|
|
*/
|
|
|
|
if (!waiter && (atomic_long_read(&lock->owner) & MUTEX_FLAG_WAITERS))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Similarly, stop spinning if we are no longer the
|
|
|
|
* first waiter.
|
|
|
|
*/
|
|
|
|
if (waiter && !__mutex_waiter_is_first(lock, waiter))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
2015-01-07 03:45:06 +08:00
|
|
|
}
|
2014-07-31 04:41:53 +08:00
|
|
|
|
2013-04-18 03:23:11 +08:00
|
|
|
/*
|
2016-12-22 02:46:37 +08:00
|
|
|
* Look out! "owner" is an entirely speculative pointer access and not
|
|
|
|
* reliable.
|
|
|
|
*
|
|
|
|
* "noinline" so that this function shows up on perf profiles.
|
2013-04-18 03:23:11 +08:00
|
|
|
*/
|
|
|
|
static noinline
|
2016-12-22 02:46:37 +08:00
|
|
|
bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner,
|
2016-12-22 02:46:38 +08:00
|
|
|
struct ww_acquire_ctx *ww_ctx, struct mutex_waiter *waiter)
|
2013-04-18 03:23:11 +08:00
|
|
|
{
|
2015-04-09 03:39:19 +08:00
|
|
|
bool ret = true;
|
2015-02-03 05:59:27 +08:00
|
|
|
|
2013-04-18 03:23:11 +08:00
|
|
|
rcu_read_lock();
|
2016-08-23 19:36:04 +08:00
|
|
|
while (__mutex_owner(lock) == owner) {
|
2015-02-03 05:59:27 +08:00
|
|
|
/*
|
|
|
|
* Ensure we emit the owner->on_cpu, dereference _after_
|
2015-04-09 03:39:19 +08:00
|
|
|
* checking lock->owner still matches owner. If that fails,
|
|
|
|
* owner might point to freed memory. If it still matches,
|
2015-02-03 05:59:27 +08:00
|
|
|
* the rcu_read_lock() ensures the memory stays valid.
|
|
|
|
*/
|
|
|
|
barrier();
|
|
|
|
|
2016-11-02 17:08:30 +08:00
|
|
|
/*
|
|
|
|
* Use vcpu_is_preempted to detect lock holder preemption issue.
|
|
|
|
*/
|
|
|
|
if (!owner->on_cpu || need_resched() ||
|
|
|
|
vcpu_is_preempted(task_cpu(owner))) {
|
2015-02-03 05:59:27 +08:00
|
|
|
ret = false;
|
|
|
|
break;
|
|
|
|
}
|
2013-04-18 03:23:11 +08:00
|
|
|
|
2016-12-22 02:46:38 +08:00
|
|
|
if (ww_ctx && !ww_mutex_spin_on_owner(lock, ww_ctx, waiter)) {
|
|
|
|
ret = false;
|
|
|
|
break;
|
2016-12-22 02:46:37 +08:00
|
|
|
}
|
|
|
|
|
2016-10-25 17:03:14 +08:00
|
|
|
cpu_relax();
|
2013-04-18 03:23:11 +08:00
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
2015-02-03 05:59:27 +08:00
|
|
|
return ret;
|
2013-04-18 03:23:11 +08:00
|
|
|
}
|
mutex: Queue mutex spinners with MCS lock to reduce cacheline contention
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option
turned on) allow multiple tasks to spin on a single mutex
concurrently. A potential problem with the current approach is
that when the mutex becomes available, all the spinning tasks
will try to acquire the mutex more or less simultaneously. As a
result, there will be a lot of cacheline bouncing especially on
systems with a large number of CPUs.
This patch tries to reduce this kind of contention by putting
the mutex spinners into a queue so that only the first one in
the queue will try to acquire the mutex. This will reduce
contention and allow all the tasks to move forward faster.
The queuing of mutex spinners is done using an MCS lock based
implementation which will further reduce contention on the mutex
cacheline than a similar ticket spinlock based implementation.
This patch will add a new field into the mutex data structure
for holding the MCS lock. This expands the mutex size by 8 bytes
for 64-bit system and 4 bytes for 32-bit system. This overhead
will be avoid if the MUTEX_SPIN_ON_OWNER option is turned off.
The following table shows the jobs per minute (JPM) scalability
data on an 8-node 80-core Westmere box with a 3.7.10 kernel. The
numactl command is used to restrict the running of the fserver
workloads to 1/2/4/8 nodes with hyperthreading off.
+-----------------+-----------+-----------+-------------+----------+
| Configuration | Mean JPM | Mean JPM | Mean JPM | % Change |
| | w/o patch | patch 1 | patches 1&2 | 1->1&2 |
+-----------------+------------------------------------------------+
| | User Range 1100 - 2000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 227972 | 227237 | 305043 | +34.2% |
| 4 nodes, HT off | 393503 | 381558 | 394650 | +3.4% |
| 2 nodes, HT off | 334957 | 325240 | 338853 | +4.2% |
| 1 node , HT off | 198141 | 197972 | 198075 | +0.1% |
+-----------------+------------------------------------------------+
| | User Range 200 - 1000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 282325 | 312870 | 332185 | +6.2% |
| 4 nodes, HT off | 390698 | 378279 | 393419 | +4.0% |
| 2 nodes, HT off | 336986 | 326543 | 340260 | +4.2% |
| 1 node , HT off | 197588 | 197622 | 197582 | 0.0% |
+-----------------+-----------+-----------+-------------+----------+
At low user range 10-100, the JPM differences were within +/-1%.
So they are not that interesting.
The fserver workload uses mutex spinning extensively. With just
the mutex change in the first patch, there is no noticeable
change in performance. Rather, there is a slight drop in
performance. This mutex spinning patch more than recovers the
lost performance and show a significant increase of +30% at high
user load with the full 8 nodes. Similar improvements were also
seen in a 3.8 kernel.
The table below shows the %time spent by different kernel
functions as reported by perf when running the fserver workload
at 1500 users with all 8 nodes.
+-----------------------+-----------+---------+-------------+
| Function | % time | % time | % time |
| | w/o patch | patch 1 | patches 1&2 |
+-----------------------+-----------+---------+-------------+
| __read_lock_failed | 34.96% | 34.91% | 29.14% |
| __write_lock_failed | 10.14% | 10.68% | 7.51% |
| mutex_spin_on_owner | 3.62% | 3.42% | 2.33% |
| mspin_lock | N/A | N/A | 9.90% |
| __mutex_lock_slowpath | 1.46% | 0.81% | 0.14% |
| _raw_spin_lock | 2.25% | 2.50% | 1.10% |
+-----------------------+-----------+---------+-------------+
The fserver workload for an 8-node system is dominated by the
contention in the read/write lock. Mutex contention also plays a
role. With the first patch only, mutex contention is down (as
shown by the __mutex_lock_slowpath figure) which help a little
bit. We saw only a few percents improvement with that.
By applying patch 2 as well, the single mutex_spin_on_owner
figure is now split out into an additional mspin_lock figure.
The time increases from 3.42% to 11.23%. It shows a great
reduction in contention among the spinners leading to a 30%
improvement. The time ratio 9.9/2.33=4.3 indicates that there
are on average 4+ spinners waiting in the spin_lock loop for
each spinner in the mutex_spin_on_owner loop. Contention in
other locking functions also go down by quite a lot.
The table below shows the performance change of both patches 1 &
2 over patch 1 alone in other AIM7 workloads (at 8 nodes,
hyperthreading off).
+--------------+---------------+----------------+-----------------+
| Workload | mean % change | mean % change | mean % change |
| | 10-100 users | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| alltests | 0.0% | -0.8% | +0.6% |
| five_sec | -0.3% | +0.8% | +0.8% |
| high_systime | +0.4% | +2.4% | +2.1% |
| new_fserver | +0.1% | +14.1% | +34.2% |
| shared | -0.5% | -0.3% | -0.4% |
| short | -1.7% | -9.8% | -8.3% |
+--------------+---------------+----------------+-----------------+
The short workload is the only one that shows a decline in
performance probably due to the spinner locking and queuing
overhead.
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Chandramouleeswaran Aswin <aswin@hp.com>
Cc: Norton Scott J <scott.norton@hp.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1366226594-5506-4-git-send-email-Waiman.Long@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-04-18 03:23:13 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Initial check for entering the mutex spinning loop
|
|
|
|
*/
|
|
|
|
static inline int mutex_can_spin_on_owner(struct mutex *lock)
|
|
|
|
{
|
2013-07-20 02:31:01 +08:00
|
|
|
struct task_struct *owner;
|
mutex: Queue mutex spinners with MCS lock to reduce cacheline contention
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option
turned on) allow multiple tasks to spin on a single mutex
concurrently. A potential problem with the current approach is
that when the mutex becomes available, all the spinning tasks
will try to acquire the mutex more or less simultaneously. As a
result, there will be a lot of cacheline bouncing especially on
systems with a large number of CPUs.
This patch tries to reduce this kind of contention by putting
the mutex spinners into a queue so that only the first one in
the queue will try to acquire the mutex. This will reduce
contention and allow all the tasks to move forward faster.
The queuing of mutex spinners is done using an MCS lock based
implementation which will further reduce contention on the mutex
cacheline than a similar ticket spinlock based implementation.
This patch will add a new field into the mutex data structure
for holding the MCS lock. This expands the mutex size by 8 bytes
for 64-bit system and 4 bytes for 32-bit system. This overhead
will be avoid if the MUTEX_SPIN_ON_OWNER option is turned off.
The following table shows the jobs per minute (JPM) scalability
data on an 8-node 80-core Westmere box with a 3.7.10 kernel. The
numactl command is used to restrict the running of the fserver
workloads to 1/2/4/8 nodes with hyperthreading off.
+-----------------+-----------+-----------+-------------+----------+
| Configuration | Mean JPM | Mean JPM | Mean JPM | % Change |
| | w/o patch | patch 1 | patches 1&2 | 1->1&2 |
+-----------------+------------------------------------------------+
| | User Range 1100 - 2000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 227972 | 227237 | 305043 | +34.2% |
| 4 nodes, HT off | 393503 | 381558 | 394650 | +3.4% |
| 2 nodes, HT off | 334957 | 325240 | 338853 | +4.2% |
| 1 node , HT off | 198141 | 197972 | 198075 | +0.1% |
+-----------------+------------------------------------------------+
| | User Range 200 - 1000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 282325 | 312870 | 332185 | +6.2% |
| 4 nodes, HT off | 390698 | 378279 | 393419 | +4.0% |
| 2 nodes, HT off | 336986 | 326543 | 340260 | +4.2% |
| 1 node , HT off | 197588 | 197622 | 197582 | 0.0% |
+-----------------+-----------+-----------+-------------+----------+
At low user range 10-100, the JPM differences were within +/-1%.
So they are not that interesting.
The fserver workload uses mutex spinning extensively. With just
the mutex change in the first patch, there is no noticeable
change in performance. Rather, there is a slight drop in
performance. This mutex spinning patch more than recovers the
lost performance and show a significant increase of +30% at high
user load with the full 8 nodes. Similar improvements were also
seen in a 3.8 kernel.
The table below shows the %time spent by different kernel
functions as reported by perf when running the fserver workload
at 1500 users with all 8 nodes.
+-----------------------+-----------+---------+-------------+
| Function | % time | % time | % time |
| | w/o patch | patch 1 | patches 1&2 |
+-----------------------+-----------+---------+-------------+
| __read_lock_failed | 34.96% | 34.91% | 29.14% |
| __write_lock_failed | 10.14% | 10.68% | 7.51% |
| mutex_spin_on_owner | 3.62% | 3.42% | 2.33% |
| mspin_lock | N/A | N/A | 9.90% |
| __mutex_lock_slowpath | 1.46% | 0.81% | 0.14% |
| _raw_spin_lock | 2.25% | 2.50% | 1.10% |
+-----------------------+-----------+---------+-------------+
The fserver workload for an 8-node system is dominated by the
contention in the read/write lock. Mutex contention also plays a
role. With the first patch only, mutex contention is down (as
shown by the __mutex_lock_slowpath figure) which help a little
bit. We saw only a few percents improvement with that.
By applying patch 2 as well, the single mutex_spin_on_owner
figure is now split out into an additional mspin_lock figure.
The time increases from 3.42% to 11.23%. It shows a great
reduction in contention among the spinners leading to a 30%
improvement. The time ratio 9.9/2.33=4.3 indicates that there
are on average 4+ spinners waiting in the spin_lock loop for
each spinner in the mutex_spin_on_owner loop. Contention in
other locking functions also go down by quite a lot.
The table below shows the performance change of both patches 1 &
2 over patch 1 alone in other AIM7 workloads (at 8 nodes,
hyperthreading off).
+--------------+---------------+----------------+-----------------+
| Workload | mean % change | mean % change | mean % change |
| | 10-100 users | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| alltests | 0.0% | -0.8% | +0.6% |
| five_sec | -0.3% | +0.8% | +0.8% |
| high_systime | +0.4% | +2.4% | +2.1% |
| new_fserver | +0.1% | +14.1% | +34.2% |
| shared | -0.5% | -0.3% | -0.4% |
| short | -1.7% | -9.8% | -8.3% |
+--------------+---------------+----------------+-----------------+
The short workload is the only one that shows a decline in
performance probably due to the spinner locking and queuing
overhead.
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Chandramouleeswaran Aswin <aswin@hp.com>
Cc: Norton Scott J <scott.norton@hp.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1366226594-5506-4-git-send-email-Waiman.Long@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-04-18 03:23:13 +08:00
|
|
|
int retval = 1;
|
|
|
|
|
2014-01-29 03:13:12 +08:00
|
|
|
if (need_resched())
|
|
|
|
return 0;
|
|
|
|
|
mutex: Queue mutex spinners with MCS lock to reduce cacheline contention
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option
turned on) allow multiple tasks to spin on a single mutex
concurrently. A potential problem with the current approach is
that when the mutex becomes available, all the spinning tasks
will try to acquire the mutex more or less simultaneously. As a
result, there will be a lot of cacheline bouncing especially on
systems with a large number of CPUs.
This patch tries to reduce this kind of contention by putting
the mutex spinners into a queue so that only the first one in
the queue will try to acquire the mutex. This will reduce
contention and allow all the tasks to move forward faster.
The queuing of mutex spinners is done using an MCS lock based
implementation which will further reduce contention on the mutex
cacheline than a similar ticket spinlock based implementation.
This patch will add a new field into the mutex data structure
for holding the MCS lock. This expands the mutex size by 8 bytes
for 64-bit system and 4 bytes for 32-bit system. This overhead
will be avoid if the MUTEX_SPIN_ON_OWNER option is turned off.
The following table shows the jobs per minute (JPM) scalability
data on an 8-node 80-core Westmere box with a 3.7.10 kernel. The
numactl command is used to restrict the running of the fserver
workloads to 1/2/4/8 nodes with hyperthreading off.
+-----------------+-----------+-----------+-------------+----------+
| Configuration | Mean JPM | Mean JPM | Mean JPM | % Change |
| | w/o patch | patch 1 | patches 1&2 | 1->1&2 |
+-----------------+------------------------------------------------+
| | User Range 1100 - 2000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 227972 | 227237 | 305043 | +34.2% |
| 4 nodes, HT off | 393503 | 381558 | 394650 | +3.4% |
| 2 nodes, HT off | 334957 | 325240 | 338853 | +4.2% |
| 1 node , HT off | 198141 | 197972 | 198075 | +0.1% |
+-----------------+------------------------------------------------+
| | User Range 200 - 1000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 282325 | 312870 | 332185 | +6.2% |
| 4 nodes, HT off | 390698 | 378279 | 393419 | +4.0% |
| 2 nodes, HT off | 336986 | 326543 | 340260 | +4.2% |
| 1 node , HT off | 197588 | 197622 | 197582 | 0.0% |
+-----------------+-----------+-----------+-------------+----------+
At low user range 10-100, the JPM differences were within +/-1%.
So they are not that interesting.
The fserver workload uses mutex spinning extensively. With just
the mutex change in the first patch, there is no noticeable
change in performance. Rather, there is a slight drop in
performance. This mutex spinning patch more than recovers the
lost performance and show a significant increase of +30% at high
user load with the full 8 nodes. Similar improvements were also
seen in a 3.8 kernel.
The table below shows the %time spent by different kernel
functions as reported by perf when running the fserver workload
at 1500 users with all 8 nodes.
+-----------------------+-----------+---------+-------------+
| Function | % time | % time | % time |
| | w/o patch | patch 1 | patches 1&2 |
+-----------------------+-----------+---------+-------------+
| __read_lock_failed | 34.96% | 34.91% | 29.14% |
| __write_lock_failed | 10.14% | 10.68% | 7.51% |
| mutex_spin_on_owner | 3.62% | 3.42% | 2.33% |
| mspin_lock | N/A | N/A | 9.90% |
| __mutex_lock_slowpath | 1.46% | 0.81% | 0.14% |
| _raw_spin_lock | 2.25% | 2.50% | 1.10% |
+-----------------------+-----------+---------+-------------+
The fserver workload for an 8-node system is dominated by the
contention in the read/write lock. Mutex contention also plays a
role. With the first patch only, mutex contention is down (as
shown by the __mutex_lock_slowpath figure) which help a little
bit. We saw only a few percents improvement with that.
By applying patch 2 as well, the single mutex_spin_on_owner
figure is now split out into an additional mspin_lock figure.
The time increases from 3.42% to 11.23%. It shows a great
reduction in contention among the spinners leading to a 30%
improvement. The time ratio 9.9/2.33=4.3 indicates that there
are on average 4+ spinners waiting in the spin_lock loop for
each spinner in the mutex_spin_on_owner loop. Contention in
other locking functions also go down by quite a lot.
The table below shows the performance change of both patches 1 &
2 over patch 1 alone in other AIM7 workloads (at 8 nodes,
hyperthreading off).
+--------------+---------------+----------------+-----------------+
| Workload | mean % change | mean % change | mean % change |
| | 10-100 users | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| alltests | 0.0% | -0.8% | +0.6% |
| five_sec | -0.3% | +0.8% | +0.8% |
| high_systime | +0.4% | +2.4% | +2.1% |
| new_fserver | +0.1% | +14.1% | +34.2% |
| shared | -0.5% | -0.3% | -0.4% |
| short | -1.7% | -9.8% | -8.3% |
+--------------+---------------+----------------+-----------------+
The short workload is the only one that shows a decline in
performance probably due to the spinner locking and queuing
overhead.
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Chandramouleeswaran Aswin <aswin@hp.com>
Cc: Norton Scott J <scott.norton@hp.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1366226594-5506-4-git-send-email-Waiman.Long@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-04-18 03:23:13 +08:00
|
|
|
rcu_read_lock();
|
2016-08-23 19:36:04 +08:00
|
|
|
owner = __mutex_owner(lock);
|
2016-11-02 17:08:30 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* As lock holder preemption issue, we both skip spinning if task is not
|
|
|
|
* on cpu or its cpu is preempted
|
|
|
|
*/
|
2013-07-20 02:31:01 +08:00
|
|
|
if (owner)
|
2016-11-02 17:08:30 +08:00
|
|
|
retval = owner->on_cpu && !vcpu_is_preempted(task_cpu(owner));
|
mutex: Queue mutex spinners with MCS lock to reduce cacheline contention
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option
turned on) allow multiple tasks to spin on a single mutex
concurrently. A potential problem with the current approach is
that when the mutex becomes available, all the spinning tasks
will try to acquire the mutex more or less simultaneously. As a
result, there will be a lot of cacheline bouncing especially on
systems with a large number of CPUs.
This patch tries to reduce this kind of contention by putting
the mutex spinners into a queue so that only the first one in
the queue will try to acquire the mutex. This will reduce
contention and allow all the tasks to move forward faster.
The queuing of mutex spinners is done using an MCS lock based
implementation which will further reduce contention on the mutex
cacheline than a similar ticket spinlock based implementation.
This patch will add a new field into the mutex data structure
for holding the MCS lock. This expands the mutex size by 8 bytes
for 64-bit system and 4 bytes for 32-bit system. This overhead
will be avoid if the MUTEX_SPIN_ON_OWNER option is turned off.
The following table shows the jobs per minute (JPM) scalability
data on an 8-node 80-core Westmere box with a 3.7.10 kernel. The
numactl command is used to restrict the running of the fserver
workloads to 1/2/4/8 nodes with hyperthreading off.
+-----------------+-----------+-----------+-------------+----------+
| Configuration | Mean JPM | Mean JPM | Mean JPM | % Change |
| | w/o patch | patch 1 | patches 1&2 | 1->1&2 |
+-----------------+------------------------------------------------+
| | User Range 1100 - 2000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 227972 | 227237 | 305043 | +34.2% |
| 4 nodes, HT off | 393503 | 381558 | 394650 | +3.4% |
| 2 nodes, HT off | 334957 | 325240 | 338853 | +4.2% |
| 1 node , HT off | 198141 | 197972 | 198075 | +0.1% |
+-----------------+------------------------------------------------+
| | User Range 200 - 1000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 282325 | 312870 | 332185 | +6.2% |
| 4 nodes, HT off | 390698 | 378279 | 393419 | +4.0% |
| 2 nodes, HT off | 336986 | 326543 | 340260 | +4.2% |
| 1 node , HT off | 197588 | 197622 | 197582 | 0.0% |
+-----------------+-----------+-----------+-------------+----------+
At low user range 10-100, the JPM differences were within +/-1%.
So they are not that interesting.
The fserver workload uses mutex spinning extensively. With just
the mutex change in the first patch, there is no noticeable
change in performance. Rather, there is a slight drop in
performance. This mutex spinning patch more than recovers the
lost performance and show a significant increase of +30% at high
user load with the full 8 nodes. Similar improvements were also
seen in a 3.8 kernel.
The table below shows the %time spent by different kernel
functions as reported by perf when running the fserver workload
at 1500 users with all 8 nodes.
+-----------------------+-----------+---------+-------------+
| Function | % time | % time | % time |
| | w/o patch | patch 1 | patches 1&2 |
+-----------------------+-----------+---------+-------------+
| __read_lock_failed | 34.96% | 34.91% | 29.14% |
| __write_lock_failed | 10.14% | 10.68% | 7.51% |
| mutex_spin_on_owner | 3.62% | 3.42% | 2.33% |
| mspin_lock | N/A | N/A | 9.90% |
| __mutex_lock_slowpath | 1.46% | 0.81% | 0.14% |
| _raw_spin_lock | 2.25% | 2.50% | 1.10% |
+-----------------------+-----------+---------+-------------+
The fserver workload for an 8-node system is dominated by the
contention in the read/write lock. Mutex contention also plays a
role. With the first patch only, mutex contention is down (as
shown by the __mutex_lock_slowpath figure) which help a little
bit. We saw only a few percents improvement with that.
By applying patch 2 as well, the single mutex_spin_on_owner
figure is now split out into an additional mspin_lock figure.
The time increases from 3.42% to 11.23%. It shows a great
reduction in contention among the spinners leading to a 30%
improvement. The time ratio 9.9/2.33=4.3 indicates that there
are on average 4+ spinners waiting in the spin_lock loop for
each spinner in the mutex_spin_on_owner loop. Contention in
other locking functions also go down by quite a lot.
The table below shows the performance change of both patches 1 &
2 over patch 1 alone in other AIM7 workloads (at 8 nodes,
hyperthreading off).
+--------------+---------------+----------------+-----------------+
| Workload | mean % change | mean % change | mean % change |
| | 10-100 users | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| alltests | 0.0% | -0.8% | +0.6% |
| five_sec | -0.3% | +0.8% | +0.8% |
| high_systime | +0.4% | +2.4% | +2.1% |
| new_fserver | +0.1% | +14.1% | +34.2% |
| shared | -0.5% | -0.3% | -0.4% |
| short | -1.7% | -9.8% | -8.3% |
+--------------+---------------+----------------+-----------------+
The short workload is the only one that shows a decline in
performance probably due to the spinner locking and queuing
overhead.
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Chandramouleeswaran Aswin <aswin@hp.com>
Cc: Norton Scott J <scott.norton@hp.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1366226594-5506-4-git-send-email-Waiman.Long@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-04-18 03:23:13 +08:00
|
|
|
rcu_read_unlock();
|
2016-08-23 19:36:04 +08:00
|
|
|
|
mutex: Queue mutex spinners with MCS lock to reduce cacheline contention
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option
turned on) allow multiple tasks to spin on a single mutex
concurrently. A potential problem with the current approach is
that when the mutex becomes available, all the spinning tasks
will try to acquire the mutex more or less simultaneously. As a
result, there will be a lot of cacheline bouncing especially on
systems with a large number of CPUs.
This patch tries to reduce this kind of contention by putting
the mutex spinners into a queue so that only the first one in
the queue will try to acquire the mutex. This will reduce
contention and allow all the tasks to move forward faster.
The queuing of mutex spinners is done using an MCS lock based
implementation which will further reduce contention on the mutex
cacheline than a similar ticket spinlock based implementation.
This patch will add a new field into the mutex data structure
for holding the MCS lock. This expands the mutex size by 8 bytes
for 64-bit system and 4 bytes for 32-bit system. This overhead
will be avoid if the MUTEX_SPIN_ON_OWNER option is turned off.
The following table shows the jobs per minute (JPM) scalability
data on an 8-node 80-core Westmere box with a 3.7.10 kernel. The
numactl command is used to restrict the running of the fserver
workloads to 1/2/4/8 nodes with hyperthreading off.
+-----------------+-----------+-----------+-------------+----------+
| Configuration | Mean JPM | Mean JPM | Mean JPM | % Change |
| | w/o patch | patch 1 | patches 1&2 | 1->1&2 |
+-----------------+------------------------------------------------+
| | User Range 1100 - 2000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 227972 | 227237 | 305043 | +34.2% |
| 4 nodes, HT off | 393503 | 381558 | 394650 | +3.4% |
| 2 nodes, HT off | 334957 | 325240 | 338853 | +4.2% |
| 1 node , HT off | 198141 | 197972 | 198075 | +0.1% |
+-----------------+------------------------------------------------+
| | User Range 200 - 1000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 282325 | 312870 | 332185 | +6.2% |
| 4 nodes, HT off | 390698 | 378279 | 393419 | +4.0% |
| 2 nodes, HT off | 336986 | 326543 | 340260 | +4.2% |
| 1 node , HT off | 197588 | 197622 | 197582 | 0.0% |
+-----------------+-----------+-----------+-------------+----------+
At low user range 10-100, the JPM differences were within +/-1%.
So they are not that interesting.
The fserver workload uses mutex spinning extensively. With just
the mutex change in the first patch, there is no noticeable
change in performance. Rather, there is a slight drop in
performance. This mutex spinning patch more than recovers the
lost performance and show a significant increase of +30% at high
user load with the full 8 nodes. Similar improvements were also
seen in a 3.8 kernel.
The table below shows the %time spent by different kernel
functions as reported by perf when running the fserver workload
at 1500 users with all 8 nodes.
+-----------------------+-----------+---------+-------------+
| Function | % time | % time | % time |
| | w/o patch | patch 1 | patches 1&2 |
+-----------------------+-----------+---------+-------------+
| __read_lock_failed | 34.96% | 34.91% | 29.14% |
| __write_lock_failed | 10.14% | 10.68% | 7.51% |
| mutex_spin_on_owner | 3.62% | 3.42% | 2.33% |
| mspin_lock | N/A | N/A | 9.90% |
| __mutex_lock_slowpath | 1.46% | 0.81% | 0.14% |
| _raw_spin_lock | 2.25% | 2.50% | 1.10% |
+-----------------------+-----------+---------+-------------+
The fserver workload for an 8-node system is dominated by the
contention in the read/write lock. Mutex contention also plays a
role. With the first patch only, mutex contention is down (as
shown by the __mutex_lock_slowpath figure) which help a little
bit. We saw only a few percents improvement with that.
By applying patch 2 as well, the single mutex_spin_on_owner
figure is now split out into an additional mspin_lock figure.
The time increases from 3.42% to 11.23%. It shows a great
reduction in contention among the spinners leading to a 30%
improvement. The time ratio 9.9/2.33=4.3 indicates that there
are on average 4+ spinners waiting in the spin_lock loop for
each spinner in the mutex_spin_on_owner loop. Contention in
other locking functions also go down by quite a lot.
The table below shows the performance change of both patches 1 &
2 over patch 1 alone in other AIM7 workloads (at 8 nodes,
hyperthreading off).
+--------------+---------------+----------------+-----------------+
| Workload | mean % change | mean % change | mean % change |
| | 10-100 users | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| alltests | 0.0% | -0.8% | +0.6% |
| five_sec | -0.3% | +0.8% | +0.8% |
| high_systime | +0.4% | +2.4% | +2.1% |
| new_fserver | +0.1% | +14.1% | +34.2% |
| shared | -0.5% | -0.3% | -0.4% |
| short | -1.7% | -9.8% | -8.3% |
+--------------+---------------+----------------+-----------------+
The short workload is the only one that shows a decline in
performance probably due to the spinner locking and queuing
overhead.
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Chandramouleeswaran Aswin <aswin@hp.com>
Cc: Norton Scott J <scott.norton@hp.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1366226594-5506-4-git-send-email-Waiman.Long@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-04-18 03:23:13 +08:00
|
|
|
/*
|
2016-08-23 19:36:04 +08:00
|
|
|
* If lock->owner is not set, the mutex has been released. Return true
|
|
|
|
* such that we'll trylock in the spin path, which is a faster option
|
|
|
|
* than the blocking slow path.
|
mutex: Queue mutex spinners with MCS lock to reduce cacheline contention
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option
turned on) allow multiple tasks to spin on a single mutex
concurrently. A potential problem with the current approach is
that when the mutex becomes available, all the spinning tasks
will try to acquire the mutex more or less simultaneously. As a
result, there will be a lot of cacheline bouncing especially on
systems with a large number of CPUs.
This patch tries to reduce this kind of contention by putting
the mutex spinners into a queue so that only the first one in
the queue will try to acquire the mutex. This will reduce
contention and allow all the tasks to move forward faster.
The queuing of mutex spinners is done using an MCS lock based
implementation which will further reduce contention on the mutex
cacheline than a similar ticket spinlock based implementation.
This patch will add a new field into the mutex data structure
for holding the MCS lock. This expands the mutex size by 8 bytes
for 64-bit system and 4 bytes for 32-bit system. This overhead
will be avoid if the MUTEX_SPIN_ON_OWNER option is turned off.
The following table shows the jobs per minute (JPM) scalability
data on an 8-node 80-core Westmere box with a 3.7.10 kernel. The
numactl command is used to restrict the running of the fserver
workloads to 1/2/4/8 nodes with hyperthreading off.
+-----------------+-----------+-----------+-------------+----------+
| Configuration | Mean JPM | Mean JPM | Mean JPM | % Change |
| | w/o patch | patch 1 | patches 1&2 | 1->1&2 |
+-----------------+------------------------------------------------+
| | User Range 1100 - 2000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 227972 | 227237 | 305043 | +34.2% |
| 4 nodes, HT off | 393503 | 381558 | 394650 | +3.4% |
| 2 nodes, HT off | 334957 | 325240 | 338853 | +4.2% |
| 1 node , HT off | 198141 | 197972 | 198075 | +0.1% |
+-----------------+------------------------------------------------+
| | User Range 200 - 1000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 282325 | 312870 | 332185 | +6.2% |
| 4 nodes, HT off | 390698 | 378279 | 393419 | +4.0% |
| 2 nodes, HT off | 336986 | 326543 | 340260 | +4.2% |
| 1 node , HT off | 197588 | 197622 | 197582 | 0.0% |
+-----------------+-----------+-----------+-------------+----------+
At low user range 10-100, the JPM differences were within +/-1%.
So they are not that interesting.
The fserver workload uses mutex spinning extensively. With just
the mutex change in the first patch, there is no noticeable
change in performance. Rather, there is a slight drop in
performance. This mutex spinning patch more than recovers the
lost performance and show a significant increase of +30% at high
user load with the full 8 nodes. Similar improvements were also
seen in a 3.8 kernel.
The table below shows the %time spent by different kernel
functions as reported by perf when running the fserver workload
at 1500 users with all 8 nodes.
+-----------------------+-----------+---------+-------------+
| Function | % time | % time | % time |
| | w/o patch | patch 1 | patches 1&2 |
+-----------------------+-----------+---------+-------------+
| __read_lock_failed | 34.96% | 34.91% | 29.14% |
| __write_lock_failed | 10.14% | 10.68% | 7.51% |
| mutex_spin_on_owner | 3.62% | 3.42% | 2.33% |
| mspin_lock | N/A | N/A | 9.90% |
| __mutex_lock_slowpath | 1.46% | 0.81% | 0.14% |
| _raw_spin_lock | 2.25% | 2.50% | 1.10% |
+-----------------------+-----------+---------+-------------+
The fserver workload for an 8-node system is dominated by the
contention in the read/write lock. Mutex contention also plays a
role. With the first patch only, mutex contention is down (as
shown by the __mutex_lock_slowpath figure) which help a little
bit. We saw only a few percents improvement with that.
By applying patch 2 as well, the single mutex_spin_on_owner
figure is now split out into an additional mspin_lock figure.
The time increases from 3.42% to 11.23%. It shows a great
reduction in contention among the spinners leading to a 30%
improvement. The time ratio 9.9/2.33=4.3 indicates that there
are on average 4+ spinners waiting in the spin_lock loop for
each spinner in the mutex_spin_on_owner loop. Contention in
other locking functions also go down by quite a lot.
The table below shows the performance change of both patches 1 &
2 over patch 1 alone in other AIM7 workloads (at 8 nodes,
hyperthreading off).
+--------------+---------------+----------------+-----------------+
| Workload | mean % change | mean % change | mean % change |
| | 10-100 users | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| alltests | 0.0% | -0.8% | +0.6% |
| five_sec | -0.3% | +0.8% | +0.8% |
| high_systime | +0.4% | +2.4% | +2.1% |
| new_fserver | +0.1% | +14.1% | +34.2% |
| shared | -0.5% | -0.3% | -0.4% |
| short | -1.7% | -9.8% | -8.3% |
+--------------+---------------+----------------+-----------------+
The short workload is the only one that shows a decline in
performance probably due to the spinner locking and queuing
overhead.
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Chandramouleeswaran Aswin <aswin@hp.com>
Cc: Norton Scott J <scott.norton@hp.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1366226594-5506-4-git-send-email-Waiman.Long@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-04-18 03:23:13 +08:00
|
|
|
*/
|
|
|
|
return retval;
|
|
|
|
}
|
2014-07-31 04:41:53 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Optimistic spinning.
|
|
|
|
*
|
|
|
|
* We try to spin for acquisition when we find that the lock owner
|
|
|
|
* is currently running on a (different) CPU and while we don't
|
|
|
|
* need to reschedule. The rationale is that if the lock owner is
|
|
|
|
* running, it is likely to release the lock soon.
|
|
|
|
*
|
|
|
|
* The mutex spinners are queued up using MCS lock so that only one
|
|
|
|
* spinner can compete for the mutex. However, if mutex spinning isn't
|
|
|
|
* going to happen, there is no point in going through the lock/unlock
|
|
|
|
* overhead.
|
|
|
|
*
|
|
|
|
* Returns true when the lock was taken, otherwise false, indicating
|
|
|
|
* that we need to jump to the slowpath and sleep.
|
2016-08-27 07:35:09 +08:00
|
|
|
*
|
|
|
|
* The waiter flag is set to true if the spinner is a waiter in the wait
|
|
|
|
* queue. The waiter-spinner will spin on the lock directly and concurrently
|
|
|
|
* with the spinner at the head of the OSQ, if present, until the owner is
|
|
|
|
* changed to itself.
|
2014-07-31 04:41:53 +08:00
|
|
|
*/
|
2016-12-23 17:36:00 +08:00
|
|
|
static __always_inline bool
|
|
|
|
mutex_optimistic_spin(struct mutex *lock, struct ww_acquire_ctx *ww_ctx,
|
2024-06-11 20:26:44 +08:00
|
|
|
struct mutex_waiter *waiter)
|
2014-07-31 04:41:53 +08:00
|
|
|
{
|
2016-08-27 07:35:09 +08:00
|
|
|
if (!waiter) {
|
|
|
|
/*
|
|
|
|
* The purpose of the mutex_can_spin_on_owner() function is
|
|
|
|
* to eliminate the overhead of osq_lock() and osq_unlock()
|
|
|
|
* in case spinning isn't possible. As a waiter-spinner
|
|
|
|
* is not going to take OSQ lock anyway, there is no need
|
|
|
|
* to call mutex_can_spin_on_owner().
|
|
|
|
*/
|
|
|
|
if (!mutex_can_spin_on_owner(lock))
|
|
|
|
goto fail;
|
2014-07-31 04:41:53 +08:00
|
|
|
|
2016-08-27 07:35:09 +08:00
|
|
|
/*
|
|
|
|
* In order to avoid a stampede of mutex spinners trying to
|
|
|
|
* acquire the mutex all at once, the spinners need to take a
|
|
|
|
* MCS (queued) lock first before spinning on the owner field.
|
|
|
|
*/
|
|
|
|
if (!osq_lock(&lock->osq))
|
|
|
|
goto fail;
|
|
|
|
}
|
2014-07-31 04:41:53 +08:00
|
|
|
|
2016-08-27 07:35:09 +08:00
|
|
|
for (;;) {
|
2014-07-31 04:41:53 +08:00
|
|
|
struct task_struct *owner;
|
|
|
|
|
2017-01-11 21:17:48 +08:00
|
|
|
/* Try to acquire the mutex... */
|
|
|
|
owner = __mutex_trylock_or_owner(lock);
|
|
|
|
if (!owner)
|
|
|
|
break;
|
2014-07-31 04:41:53 +08:00
|
|
|
|
|
|
|
/*
|
2017-01-11 21:17:48 +08:00
|
|
|
* There's an owner, wait for it to either
|
2014-07-31 04:41:53 +08:00
|
|
|
* release the lock or go to sleep.
|
|
|
|
*/
|
2016-12-22 02:46:38 +08:00
|
|
|
if (!mutex_spin_on_owner(lock, owner, ww_ctx, waiter))
|
2017-01-11 21:17:48 +08:00
|
|
|
goto fail_unlock;
|
2016-08-27 07:35:09 +08:00
|
|
|
|
2014-07-31 04:41:53 +08:00
|
|
|
/*
|
|
|
|
* The cpu_relax() call is a compiler barrier which forces
|
|
|
|
* everything in this loop to be re-loaded. We don't need
|
|
|
|
* memory barriers as we'll eventually observe the right
|
|
|
|
* values at the cost of a few extra spins.
|
|
|
|
*/
|
2016-10-25 17:03:14 +08:00
|
|
|
cpu_relax();
|
2014-07-31 04:41:53 +08:00
|
|
|
}
|
|
|
|
|
2016-08-27 07:35:09 +08:00
|
|
|
if (!waiter)
|
|
|
|
osq_unlock(&lock->osq);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
|
|
fail_unlock:
|
|
|
|
if (!waiter)
|
|
|
|
osq_unlock(&lock->osq);
|
|
|
|
|
|
|
|
fail:
|
2014-07-31 04:41:53 +08:00
|
|
|
/*
|
|
|
|
* If we fell out of the spin path because of need_resched(),
|
|
|
|
* reschedule now, before we try-lock the mutex. This avoids getting
|
|
|
|
* scheduled out right after we obtained the mutex.
|
|
|
|
*/
|
2014-09-24 16:18:46 +08:00
|
|
|
if (need_resched()) {
|
|
|
|
/*
|
|
|
|
* We _should_ have TASK_RUNNING here, but just in case
|
|
|
|
* we do not, make it so, otherwise we might get stuck.
|
|
|
|
*/
|
|
|
|
__set_current_state(TASK_RUNNING);
|
2014-07-31 04:41:53 +08:00
|
|
|
schedule_preempt_disabled();
|
2014-09-24 16:18:46 +08:00
|
|
|
}
|
2014-07-31 04:41:53 +08:00
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#else
|
2016-12-23 17:36:00 +08:00
|
|
|
static __always_inline bool
|
|
|
|
mutex_optimistic_spin(struct mutex *lock, struct ww_acquire_ctx *ww_ctx,
|
2024-06-11 20:26:44 +08:00
|
|
|
struct mutex_waiter *waiter)
|
2014-07-31 04:41:53 +08:00
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
2013-04-18 03:23:11 +08:00
|
|
|
#endif
|
|
|
|
|
2016-08-23 19:36:04 +08:00
|
|
|
static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigned long ip);
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2010-09-03 06:48:16 +08:00
|
|
|
/**
|
2006-01-10 07:59:19 +08:00
|
|
|
* mutex_unlock - release the mutex
|
|
|
|
* @lock: the mutex to be released
|
|
|
|
*
|
|
|
|
* Unlock a mutex that has been locked by this task previously.
|
|
|
|
*
|
|
|
|
* This function must not be used in interrupt context. Unlocking
|
|
|
|
* of a not locked mutex is not allowed.
|
|
|
|
*
|
|
|
|
* This function is similar to (but not equivalent to) up().
|
|
|
|
*/
|
2008-02-08 20:19:53 +08:00
|
|
|
void __sched mutex_unlock(struct mutex *lock)
|
2006-01-10 07:59:19 +08:00
|
|
|
{
|
2016-08-23 19:36:04 +08:00
|
|
|
#ifndef CONFIG_DEBUG_LOCK_ALLOC
|
|
|
|
if (__mutex_unlock_fast(lock))
|
|
|
|
return;
|
2009-01-12 21:01:47 +08:00
|
|
|
#endif
|
2016-08-23 19:36:04 +08:00
|
|
|
__mutex_unlock_slowpath(lock, _RET_IP_);
|
2006-01-10 07:59:19 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mutex_unlock);
|
|
|
|
|
2013-06-24 16:30:04 +08:00
|
|
|
/**
|
|
|
|
* ww_mutex_unlock - release the w/w mutex
|
|
|
|
* @lock: the mutex to be released
|
|
|
|
*
|
|
|
|
* Unlock a mutex that has been locked by this task previously with any of the
|
|
|
|
* ww_mutex_lock* functions (with or without an acquire context). It is
|
|
|
|
* forbidden to release the locks after releasing the acquire context.
|
|
|
|
*
|
|
|
|
* This function must not be used in interrupt context. Unlocking
|
|
|
|
* of a unlocked mutex is not allowed.
|
|
|
|
*/
|
|
|
|
void __sched ww_mutex_unlock(struct ww_mutex *lock)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* The unlocking fastpath is the 0->1 transition from 'locked'
|
|
|
|
* into 'unlocked' state:
|
|
|
|
*/
|
|
|
|
if (lock->ctx) {
|
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
|
|
|
DEBUG_LOCKS_WARN_ON(!lock->ctx->acquired);
|
|
|
|
#endif
|
|
|
|
if (lock->ctx->acquired > 0)
|
|
|
|
lock->ctx->acquired--;
|
|
|
|
lock->ctx = NULL;
|
|
|
|
}
|
|
|
|
|
2016-08-23 19:36:04 +08:00
|
|
|
mutex_unlock(&lock->base);
|
2013-06-24 16:30:04 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ww_mutex_unlock);
|
|
|
|
|
2018-06-15 16:07:12 +08:00
|
|
|
|
|
|
|
static __always_inline int __sched
|
|
|
|
__ww_mutex_kill(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
|
|
|
|
{
|
|
|
|
if (ww_ctx->acquired > 0) {
|
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
|
|
|
struct ww_mutex *ww;
|
|
|
|
|
|
|
|
ww = container_of(lock, struct ww_mutex, base);
|
|
|
|
DEBUG_LOCKS_WARN_ON(ww_ctx->contending_lock);
|
|
|
|
ww_ctx->contending_lock = ww;
|
|
|
|
#endif
|
|
|
|
return -EDEADLK;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2018-06-15 16:17:38 +08:00
|
|
|
* Check the wound condition for the current lock acquire.
|
|
|
|
*
|
|
|
|
* Wound-Wait: If we're wounded, kill ourself.
|
2018-06-15 16:07:12 +08:00
|
|
|
*
|
|
|
|
* Wait-Die: If we're trying to acquire a lock already held by an older
|
|
|
|
* context, kill ourselves.
|
|
|
|
*
|
|
|
|
* Since __ww_mutex_add_waiter() orders the wait-list on stamp, we only have to
|
|
|
|
* look at waiters before us in the wait-list.
|
|
|
|
*/
|
2013-06-24 16:30:04 +08:00
|
|
|
static inline int __sched
|
2018-06-15 16:07:12 +08:00
|
|
|
__ww_mutex_check_kill(struct mutex *lock, struct mutex_waiter *waiter,
|
|
|
|
struct ww_acquire_ctx *ctx)
|
2013-06-24 16:30:04 +08:00
|
|
|
{
|
|
|
|
struct ww_mutex *ww = container_of(lock, struct ww_mutex, base);
|
2015-02-23 11:31:41 +08:00
|
|
|
struct ww_acquire_ctx *hold_ctx = READ_ONCE(ww->ctx);
|
2016-12-22 02:46:35 +08:00
|
|
|
struct mutex_waiter *cur;
|
2013-06-24 16:30:04 +08:00
|
|
|
|
2018-06-15 16:07:12 +08:00
|
|
|
if (ctx->acquired == 0)
|
|
|
|
return 0;
|
|
|
|
|
2018-06-15 16:17:38 +08:00
|
|
|
if (!ctx->is_wait_die) {
|
|
|
|
if (ctx->wounded)
|
|
|
|
return __ww_mutex_kill(lock, ctx);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-12-22 02:46:35 +08:00
|
|
|
if (hold_ctx && __ww_ctx_stamp_after(ctx, hold_ctx))
|
2018-06-15 16:07:12 +08:00
|
|
|
return __ww_mutex_kill(lock, ctx);
|
2013-06-24 16:30:04 +08:00
|
|
|
|
2016-12-22 02:46:35 +08:00
|
|
|
/*
|
|
|
|
* If there is a waiter in front of us that has a context, then its
|
2018-06-15 16:07:12 +08:00
|
|
|
* stamp is earlier than ours and we must kill ourself.
|
2016-12-22 02:46:35 +08:00
|
|
|
*/
|
|
|
|
cur = waiter;
|
|
|
|
list_for_each_entry_continue_reverse(cur, &lock->wait_list, list) {
|
2018-06-15 16:07:12 +08:00
|
|
|
if (!cur->ww_ctx)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
return __ww_mutex_kill(lock, ctx);
|
2013-06-24 16:30:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-06-15 16:07:12 +08:00
|
|
|
/*
|
|
|
|
* Add @waiter to the wait-list, keep the wait-list ordered by stamp, smallest
|
|
|
|
* first. Such that older contexts are preferred to acquire the lock over
|
|
|
|
* younger contexts.
|
|
|
|
*
|
|
|
|
* Waiters without context are interspersed in FIFO order.
|
|
|
|
*
|
|
|
|
* Furthermore, for Wait-Die kill ourself immediately when possible (there are
|
2018-06-15 16:17:38 +08:00
|
|
|
* older contexts already waiting) to avoid unnecessary waiting and for
|
|
|
|
* Wound-Wait ensure we wound the owning context when it is younger.
|
2018-06-15 16:07:12 +08:00
|
|
|
*/
|
2016-12-22 02:46:34 +08:00
|
|
|
static inline int __sched
|
|
|
|
__ww_mutex_add_waiter(struct mutex_waiter *waiter,
|
|
|
|
struct mutex *lock,
|
|
|
|
struct ww_acquire_ctx *ww_ctx)
|
|
|
|
{
|
|
|
|
struct mutex_waiter *cur;
|
|
|
|
struct list_head *pos;
|
2018-06-15 16:17:38 +08:00
|
|
|
bool is_wait_die;
|
2016-12-22 02:46:34 +08:00
|
|
|
|
|
|
|
if (!ww_ctx) {
|
2018-06-15 16:17:38 +08:00
|
|
|
__mutex_add_waiter(lock, waiter, &lock->wait_list);
|
2013-06-24 16:30:04 +08:00
|
|
|
return 0;
|
2016-12-22 02:46:34 +08:00
|
|
|
}
|
2013-06-24 16:30:04 +08:00
|
|
|
|
2018-06-15 16:17:38 +08:00
|
|
|
is_wait_die = ww_ctx->is_wait_die;
|
|
|
|
|
2016-12-22 02:46:34 +08:00
|
|
|
/*
|
|
|
|
* Add the waiter before the first waiter with a higher stamp.
|
|
|
|
* Waiters without a context are skipped to avoid starving
|
2018-06-15 16:17:38 +08:00
|
|
|
* them. Wait-Die waiters may die here. Wound-Wait waiters
|
|
|
|
* never die here, but they are sorted in stamp order and
|
|
|
|
* may wound the lock holder.
|
2016-12-22 02:46:34 +08:00
|
|
|
*/
|
|
|
|
pos = &lock->wait_list;
|
|
|
|
list_for_each_entry_reverse(cur, &lock->wait_list, list) {
|
|
|
|
if (!cur->ww_ctx)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (__ww_ctx_stamp_after(ww_ctx, cur->ww_ctx)) {
|
2018-06-15 16:07:12 +08:00
|
|
|
/*
|
|
|
|
* Wait-Die: if we find an older context waiting, there
|
|
|
|
* is no point in queueing behind it, as we'd have to
|
|
|
|
* die the moment it would acquire the lock.
|
|
|
|
*/
|
2018-06-15 16:17:38 +08:00
|
|
|
if (is_wait_die) {
|
|
|
|
int ret = __ww_mutex_kill(lock, ww_ctx);
|
2016-12-22 02:46:34 +08:00
|
|
|
|
2018-06-15 16:17:38 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2016-12-22 02:46:34 +08:00
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
pos = &cur->list;
|
2016-12-22 02:46:35 +08:00
|
|
|
|
2018-06-15 16:07:12 +08:00
|
|
|
/* Wait-Die: ensure younger waiters die. */
|
|
|
|
__ww_mutex_die(lock, cur, ww_ctx);
|
2013-06-24 16:30:04 +08:00
|
|
|
}
|
|
|
|
|
2018-06-15 16:17:38 +08:00
|
|
|
__mutex_add_waiter(lock, waiter, pos);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wound-Wait: if we're blocking on a mutex owned by a younger context,
|
|
|
|
* wound that such that we might proceed.
|
|
|
|
*/
|
|
|
|
if (!is_wait_die) {
|
|
|
|
struct ww_mutex *ww = container_of(lock, struct ww_mutex, base);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* See ww_mutex_set_context_fastpath(). Orders setting
|
|
|
|
* MUTEX_FLAG_WAITERS vs the ww->ctx load,
|
|
|
|
* such that either we or the fastpath will wound @ww->ctx.
|
|
|
|
*/
|
|
|
|
smp_mb();
|
|
|
|
__ww_mutex_wound(lock, ww_ctx, ww->ctx);
|
|
|
|
}
|
2018-06-15 16:07:12 +08:00
|
|
|
|
2013-06-24 16:30:04 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-01-10 07:59:19 +08:00
|
|
|
/*
|
|
|
|
* Lock a mutex (possibly interruptible), slowpath:
|
|
|
|
*/
|
2013-06-24 16:30:04 +08:00
|
|
|
static __always_inline int __sched
|
2007-10-12 04:11:12 +08:00
|
|
|
__mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
|
2013-06-24 16:30:04 +08:00
|
|
|
struct lockdep_map *nest_lock, unsigned long ip,
|
2013-10-17 18:45:29 +08:00
|
|
|
struct ww_acquire_ctx *ww_ctx, const bool use_ww_ctx)
|
2006-01-10 07:59:19 +08:00
|
|
|
{
|
|
|
|
struct mutex_waiter waiter;
|
2016-08-27 07:35:08 +08:00
|
|
|
struct ww_mutex *ww;
|
2013-06-24 16:30:04 +08:00
|
|
|
int ret;
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2024-06-11 20:26:44 +08:00
|
|
|
if (!use_ww_ctx)
|
|
|
|
ww_ctx = NULL;
|
|
|
|
|
2016-12-23 17:36:00 +08:00
|
|
|
might_sleep();
|
2016-12-22 02:46:32 +08:00
|
|
|
|
2019-07-03 17:21:26 +08:00
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
|
|
|
DEBUG_LOCKS_WARN_ON(lock->magic != lock);
|
|
|
|
#endif
|
|
|
|
|
2016-12-23 17:36:00 +08:00
|
|
|
ww = container_of(lock, struct ww_mutex, base);
|
2024-06-11 20:26:44 +08:00
|
|
|
if (ww_ctx) {
|
2016-05-27 04:08:17 +08:00
|
|
|
if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
|
|
|
|
return -EALREADY;
|
2018-06-15 16:17:38 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Reset the wounded flag after a kill. No other process can
|
|
|
|
* race and wound us here since they can't have a valid owner
|
|
|
|
* pointer if we don't have any locks held.
|
|
|
|
*/
|
|
|
|
if (ww_ctx->acquired == 0)
|
|
|
|
ww_ctx->wounded = 0;
|
2016-05-27 04:08:17 +08:00
|
|
|
}
|
|
|
|
|
2009-01-14 22:36:26 +08:00
|
|
|
preempt_disable();
|
2011-05-25 08:12:03 +08:00
|
|
|
mutex_acquire_nest(&lock->dep_map, subclass, 0, nest_lock, ip);
|
2009-12-03 03:49:16 +08:00
|
|
|
|
2017-01-11 21:17:48 +08:00
|
|
|
if (__mutex_trylock(lock) ||
|
2024-06-11 20:26:44 +08:00
|
|
|
mutex_optimistic_spin(lock, ww_ctx, NULL)) {
|
2014-07-31 04:41:53 +08:00
|
|
|
/* got the lock, yay! */
|
2016-08-23 19:36:04 +08:00
|
|
|
lock_acquired(&lock->dep_map, ip);
|
2024-06-11 20:26:44 +08:00
|
|
|
if (ww_ctx)
|
2016-08-23 19:36:04 +08:00
|
|
|
ww_mutex_set_context_fastpath(ww, ww_ctx);
|
2014-07-31 04:41:53 +08:00
|
|
|
preempt_enable();
|
|
|
|
return 0;
|
2009-01-12 21:01:47 +08:00
|
|
|
}
|
2014-07-31 04:41:53 +08:00
|
|
|
|
2017-01-17 23:06:09 +08:00
|
|
|
spin_lock(&lock->wait_lock);
|
2014-06-12 02:37:21 +08:00
|
|
|
/*
|
2016-08-23 19:36:04 +08:00
|
|
|
* After waiting to acquire the wait_lock, try again.
|
2014-06-12 02:37:21 +08:00
|
|
|
*/
|
2016-12-22 02:46:36 +08:00
|
|
|
if (__mutex_trylock(lock)) {
|
2024-06-11 20:26:44 +08:00
|
|
|
if (ww_ctx)
|
2018-06-15 16:07:12 +08:00
|
|
|
__ww_mutex_check_waiters(lock, ww_ctx);
|
2016-12-22 02:46:36 +08:00
|
|
|
|
2013-06-29 04:13:18 +08:00
|
|
|
goto skip_wait;
|
2016-12-22 02:46:36 +08:00
|
|
|
}
|
2013-06-29 04:13:18 +08:00
|
|
|
|
2006-07-03 15:24:33 +08:00
|
|
|
debug_mutex_lock_common(lock, &waiter);
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2016-12-22 02:46:34 +08:00
|
|
|
lock_contended(&lock->dep_map, ip);
|
|
|
|
|
|
|
|
if (!use_ww_ctx) {
|
|
|
|
/* add waiting tasks to the end of the waitqueue (FIFO): */
|
2018-06-15 16:17:38 +08:00
|
|
|
__mutex_add_waiter(lock, &waiter, &lock->wait_list);
|
|
|
|
|
2016-12-22 02:46:39 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
|
|
|
waiter.ww_ctx = MUTEX_POISON_WW_CTX;
|
|
|
|
#endif
|
2016-12-22 02:46:34 +08:00
|
|
|
} else {
|
2018-06-15 16:07:12 +08:00
|
|
|
/*
|
|
|
|
* Add in stamp order, waking up waiters that must kill
|
|
|
|
* themselves.
|
|
|
|
*/
|
2016-12-22 02:46:34 +08:00
|
|
|
ret = __ww_mutex_add_waiter(&waiter, lock, ww_ctx);
|
|
|
|
if (ret)
|
2018-06-15 16:07:12 +08:00
|
|
|
goto err_early_kill;
|
2016-12-22 02:46:34 +08:00
|
|
|
|
|
|
|
waiter.ww_ctx = ww_ctx;
|
|
|
|
}
|
|
|
|
|
2017-01-04 05:43:13 +08:00
|
|
|
waiter.task = current;
|
2006-01-10 07:59:19 +08:00
|
|
|
|
sched/core: Remove set_task_state()
This is a nasty interface and setting the state of a foreign task must
not be done. As of the following commit:
be628be0956 ("bcache: Make gc wakeup sane, remove set_task_state()")
... everyone in the kernel calls set_task_state() with current, allowing
the helper to be removed.
However, as the comment indicates, it is still around for those archs
where computing current is more expensive than using a pointer, at least
in theory. An important arch that is affected is arm64, however this has
been addressed now [1] and performance is up to par making no difference
with either calls.
Of all the callers, if any, it's the locking bits that would care most
about this -- ie: we end up passing a tsk pointer to a lot of the lock
slowpath, and setting ->state on that. The following numbers are based
on two tests: a custom ad-hoc microbenchmark that just measures
latencies (for ~65 million calls) between get_task_state() vs
get_current_state().
Secondly for a higher overview, an unlink microbenchmark was used,
which pounds on a single file with open, close,unlink combos with
increasing thread counts (up to 4x ncpus). While the workload is quite
unrealistic, it does contend a lot on the inode mutex or now rwsem.
[1] https://lkml.kernel.org/r/1483468021-8237-1-git-send-email-mark.rutland@arm.com
== 1. x86-64 ==
Avg runtime set_task_state(): 601 msecs
Avg runtime set_current_state(): 552 msecs
vanilla dirty
Hmean unlink1-processes-2 36089.26 ( 0.00%) 38977.33 ( 8.00%)
Hmean unlink1-processes-5 28555.01 ( 0.00%) 29832.55 ( 4.28%)
Hmean unlink1-processes-8 37323.75 ( 0.00%) 44974.57 ( 20.50%)
Hmean unlink1-processes-12 43571.88 ( 0.00%) 44283.01 ( 1.63%)
Hmean unlink1-processes-21 34431.52 ( 0.00%) 38284.45 ( 11.19%)
Hmean unlink1-processes-30 34813.26 ( 0.00%) 37975.17 ( 9.08%)
Hmean unlink1-processes-48 37048.90 ( 0.00%) 39862.78 ( 7.59%)
Hmean unlink1-processes-79 35630.01 ( 0.00%) 36855.30 ( 3.44%)
Hmean unlink1-processes-110 36115.85 ( 0.00%) 39843.91 ( 10.32%)
Hmean unlink1-processes-141 32546.96 ( 0.00%) 35418.52 ( 8.82%)
Hmean unlink1-processes-172 34674.79 ( 0.00%) 36899.21 ( 6.42%)
Hmean unlink1-processes-203 37303.11 ( 0.00%) 36393.04 ( -2.44%)
Hmean unlink1-processes-224 35712.13 ( 0.00%) 36685.96 ( 2.73%)
== 2. ppc64le ==
Avg runtime set_task_state(): 938 msecs
Avg runtime set_current_state: 940 msecs
vanilla dirty
Hmean unlink1-processes-2 19269.19 ( 0.00%) 30704.50 ( 59.35%)
Hmean unlink1-processes-5 20106.15 ( 0.00%) 21804.15 ( 8.45%)
Hmean unlink1-processes-8 17496.97 ( 0.00%) 17243.28 ( -1.45%)
Hmean unlink1-processes-12 14224.15 ( 0.00%) 17240.21 ( 21.20%)
Hmean unlink1-processes-21 14155.66 ( 0.00%) 15681.23 ( 10.78%)
Hmean unlink1-processes-30 14450.70 ( 0.00%) 15995.83 ( 10.69%)
Hmean unlink1-processes-48 16945.57 ( 0.00%) 16370.42 ( -3.39%)
Hmean unlink1-processes-79 15788.39 ( 0.00%) 14639.27 ( -7.28%)
Hmean unlink1-processes-110 14268.48 ( 0.00%) 14377.40 ( 0.76%)
Hmean unlink1-processes-141 14023.65 ( 0.00%) 16271.69 ( 16.03%)
Hmean unlink1-processes-172 13417.62 ( 0.00%) 16067.55 ( 19.75%)
Hmean unlink1-processes-203 15293.08 ( 0.00%) 15440.40 ( 0.96%)
Hmean unlink1-processes-234 13719.32 ( 0.00%) 16190.74 ( 18.01%)
Hmean unlink1-processes-265 16400.97 ( 0.00%) 16115.22 ( -1.74%)
Hmean unlink1-processes-296 14388.60 ( 0.00%) 16216.13 ( 12.70%)
Hmean unlink1-processes-320 15771.85 ( 0.00%) 15905.96 ( 0.85%)
x86-64 (known to be fast for get_current()/this_cpu_read_stable() caching)
and ppc64 (with paca) show similar improvements in the unlink microbenches.
The small delta for ppc64 (2ms), does not represent the gains on the unlink
runs. In the case of x86, there was a decent amount of variation in the
latency runs, but always within a 20 to 50ms increase), ppc was more constant.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dave@stgolabs.net
Cc: mark.rutland@arm.com
Link: http://lkml.kernel.org/r/1483479794-14013-5-git-send-email-dave@stgolabs.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-04 05:43:14 +08:00
|
|
|
set_current_state(state);
|
2006-01-10 07:59:19 +08:00
|
|
|
for (;;) {
|
2024-06-12 13:13:20 +08:00
|
|
|
bool first;
|
|
|
|
|
2016-09-02 19:42:12 +08:00
|
|
|
/*
|
|
|
|
* Once we hold wait_lock, we're serialized against
|
|
|
|
* mutex_unlock() handing the lock off to us, do a trylock
|
|
|
|
* before testing the error conditions to make sure we pick up
|
|
|
|
* the handoff.
|
|
|
|
*/
|
2017-01-11 21:17:48 +08:00
|
|
|
if (__mutex_trylock(lock))
|
2016-09-02 19:42:12 +08:00
|
|
|
goto acquired;
|
2006-01-10 07:59:19 +08:00
|
|
|
|
|
|
|
/*
|
2018-06-15 16:07:12 +08:00
|
|
|
* Check for signals and kill conditions while holding
|
2016-09-02 19:42:12 +08:00
|
|
|
* wait_lock. This ensures the lock cancellation is ordered
|
|
|
|
* against mutex_unlock() and wake-ups do not go missing.
|
2006-01-10 07:59:19 +08:00
|
|
|
*/
|
2019-01-04 07:28:44 +08:00
|
|
|
if (signal_pending_state(state, current)) {
|
2013-06-24 16:30:04 +08:00
|
|
|
ret = -EINTR;
|
|
|
|
goto err;
|
|
|
|
}
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2024-06-11 20:26:44 +08:00
|
|
|
if (ww_ctx) {
|
2018-06-15 16:07:12 +08:00
|
|
|
ret = __ww_mutex_check_kill(lock, &waiter, ww_ctx);
|
2013-06-24 16:30:04 +08:00
|
|
|
if (ret)
|
|
|
|
goto err;
|
2006-01-10 07:59:19 +08:00
|
|
|
}
|
2013-06-24 16:30:04 +08:00
|
|
|
|
2017-01-17 23:06:09 +08:00
|
|
|
spin_unlock(&lock->wait_lock);
|
2011-03-21 19:33:18 +08:00
|
|
|
schedule_preempt_disabled();
|
2016-08-23 20:40:16 +08:00
|
|
|
|
2024-06-12 13:13:20 +08:00
|
|
|
first = __mutex_waiter_is_first(lock, &waiter);
|
|
|
|
if (first)
|
|
|
|
__mutex_set_flag(lock, MUTEX_FLAG_HANDOFF);
|
2016-09-02 19:42:12 +08:00
|
|
|
|
sched/core: Remove set_task_state()
This is a nasty interface and setting the state of a foreign task must
not be done. As of the following commit:
be628be0956 ("bcache: Make gc wakeup sane, remove set_task_state()")
... everyone in the kernel calls set_task_state() with current, allowing
the helper to be removed.
However, as the comment indicates, it is still around for those archs
where computing current is more expensive than using a pointer, at least
in theory. An important arch that is affected is arm64, however this has
been addressed now [1] and performance is up to par making no difference
with either calls.
Of all the callers, if any, it's the locking bits that would care most
about this -- ie: we end up passing a tsk pointer to a lot of the lock
slowpath, and setting ->state on that. The following numbers are based
on two tests: a custom ad-hoc microbenchmark that just measures
latencies (for ~65 million calls) between get_task_state() vs
get_current_state().
Secondly for a higher overview, an unlink microbenchmark was used,
which pounds on a single file with open, close,unlink combos with
increasing thread counts (up to 4x ncpus). While the workload is quite
unrealistic, it does contend a lot on the inode mutex or now rwsem.
[1] https://lkml.kernel.org/r/1483468021-8237-1-git-send-email-mark.rutland@arm.com
== 1. x86-64 ==
Avg runtime set_task_state(): 601 msecs
Avg runtime set_current_state(): 552 msecs
vanilla dirty
Hmean unlink1-processes-2 36089.26 ( 0.00%) 38977.33 ( 8.00%)
Hmean unlink1-processes-5 28555.01 ( 0.00%) 29832.55 ( 4.28%)
Hmean unlink1-processes-8 37323.75 ( 0.00%) 44974.57 ( 20.50%)
Hmean unlink1-processes-12 43571.88 ( 0.00%) 44283.01 ( 1.63%)
Hmean unlink1-processes-21 34431.52 ( 0.00%) 38284.45 ( 11.19%)
Hmean unlink1-processes-30 34813.26 ( 0.00%) 37975.17 ( 9.08%)
Hmean unlink1-processes-48 37048.90 ( 0.00%) 39862.78 ( 7.59%)
Hmean unlink1-processes-79 35630.01 ( 0.00%) 36855.30 ( 3.44%)
Hmean unlink1-processes-110 36115.85 ( 0.00%) 39843.91 ( 10.32%)
Hmean unlink1-processes-141 32546.96 ( 0.00%) 35418.52 ( 8.82%)
Hmean unlink1-processes-172 34674.79 ( 0.00%) 36899.21 ( 6.42%)
Hmean unlink1-processes-203 37303.11 ( 0.00%) 36393.04 ( -2.44%)
Hmean unlink1-processes-224 35712.13 ( 0.00%) 36685.96 ( 2.73%)
== 2. ppc64le ==
Avg runtime set_task_state(): 938 msecs
Avg runtime set_current_state: 940 msecs
vanilla dirty
Hmean unlink1-processes-2 19269.19 ( 0.00%) 30704.50 ( 59.35%)
Hmean unlink1-processes-5 20106.15 ( 0.00%) 21804.15 ( 8.45%)
Hmean unlink1-processes-8 17496.97 ( 0.00%) 17243.28 ( -1.45%)
Hmean unlink1-processes-12 14224.15 ( 0.00%) 17240.21 ( 21.20%)
Hmean unlink1-processes-21 14155.66 ( 0.00%) 15681.23 ( 10.78%)
Hmean unlink1-processes-30 14450.70 ( 0.00%) 15995.83 ( 10.69%)
Hmean unlink1-processes-48 16945.57 ( 0.00%) 16370.42 ( -3.39%)
Hmean unlink1-processes-79 15788.39 ( 0.00%) 14639.27 ( -7.28%)
Hmean unlink1-processes-110 14268.48 ( 0.00%) 14377.40 ( 0.76%)
Hmean unlink1-processes-141 14023.65 ( 0.00%) 16271.69 ( 16.03%)
Hmean unlink1-processes-172 13417.62 ( 0.00%) 16067.55 ( 19.75%)
Hmean unlink1-processes-203 15293.08 ( 0.00%) 15440.40 ( 0.96%)
Hmean unlink1-processes-234 13719.32 ( 0.00%) 16190.74 ( 18.01%)
Hmean unlink1-processes-265 16400.97 ( 0.00%) 16115.22 ( -1.74%)
Hmean unlink1-processes-296 14388.60 ( 0.00%) 16216.13 ( 12.70%)
Hmean unlink1-processes-320 15771.85 ( 0.00%) 15905.96 ( 0.85%)
x86-64 (known to be fast for get_current()/this_cpu_read_stable() caching)
and ppc64 (with paca) show similar improvements in the unlink microbenches.
The small delta for ppc64 (2ms), does not represent the gains on the unlink
runs. In the case of x86, there was a decent amount of variation in the
latency runs, but always within a 20 to 50ms increase), ppc was more constant.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dave@stgolabs.net
Cc: mark.rutland@arm.com
Link: http://lkml.kernel.org/r/1483479794-14013-5-git-send-email-dave@stgolabs.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-04 05:43:14 +08:00
|
|
|
set_current_state(state);
|
2016-09-02 19:42:12 +08:00
|
|
|
/*
|
|
|
|
* Here we order against unlock; we must either see it change
|
|
|
|
* state back to RUNNING and fall through the next schedule(),
|
|
|
|
* or we must see its unlock and acquire.
|
|
|
|
*/
|
2017-01-11 21:17:48 +08:00
|
|
|
if (__mutex_trylock(lock) ||
|
2024-06-11 20:26:44 +08:00
|
|
|
(first && mutex_optimistic_spin(lock, ww_ctx, &waiter)))
|
2016-09-02 19:42:12 +08:00
|
|
|
break;
|
|
|
|
|
2017-01-17 23:06:09 +08:00
|
|
|
spin_lock(&lock->wait_lock);
|
2006-01-10 07:59:19 +08:00
|
|
|
}
|
2017-01-17 23:06:09 +08:00
|
|
|
spin_lock(&lock->wait_lock);
|
2016-09-02 19:42:12 +08:00
|
|
|
acquired:
|
sched/core: Remove set_task_state()
This is a nasty interface and setting the state of a foreign task must
not be done. As of the following commit:
be628be0956 ("bcache: Make gc wakeup sane, remove set_task_state()")
... everyone in the kernel calls set_task_state() with current, allowing
the helper to be removed.
However, as the comment indicates, it is still around for those archs
where computing current is more expensive than using a pointer, at least
in theory. An important arch that is affected is arm64, however this has
been addressed now [1] and performance is up to par making no difference
with either calls.
Of all the callers, if any, it's the locking bits that would care most
about this -- ie: we end up passing a tsk pointer to a lot of the lock
slowpath, and setting ->state on that. The following numbers are based
on two tests: a custom ad-hoc microbenchmark that just measures
latencies (for ~65 million calls) between get_task_state() vs
get_current_state().
Secondly for a higher overview, an unlink microbenchmark was used,
which pounds on a single file with open, close,unlink combos with
increasing thread counts (up to 4x ncpus). While the workload is quite
unrealistic, it does contend a lot on the inode mutex or now rwsem.
[1] https://lkml.kernel.org/r/1483468021-8237-1-git-send-email-mark.rutland@arm.com
== 1. x86-64 ==
Avg runtime set_task_state(): 601 msecs
Avg runtime set_current_state(): 552 msecs
vanilla dirty
Hmean unlink1-processes-2 36089.26 ( 0.00%) 38977.33 ( 8.00%)
Hmean unlink1-processes-5 28555.01 ( 0.00%) 29832.55 ( 4.28%)
Hmean unlink1-processes-8 37323.75 ( 0.00%) 44974.57 ( 20.50%)
Hmean unlink1-processes-12 43571.88 ( 0.00%) 44283.01 ( 1.63%)
Hmean unlink1-processes-21 34431.52 ( 0.00%) 38284.45 ( 11.19%)
Hmean unlink1-processes-30 34813.26 ( 0.00%) 37975.17 ( 9.08%)
Hmean unlink1-processes-48 37048.90 ( 0.00%) 39862.78 ( 7.59%)
Hmean unlink1-processes-79 35630.01 ( 0.00%) 36855.30 ( 3.44%)
Hmean unlink1-processes-110 36115.85 ( 0.00%) 39843.91 ( 10.32%)
Hmean unlink1-processes-141 32546.96 ( 0.00%) 35418.52 ( 8.82%)
Hmean unlink1-processes-172 34674.79 ( 0.00%) 36899.21 ( 6.42%)
Hmean unlink1-processes-203 37303.11 ( 0.00%) 36393.04 ( -2.44%)
Hmean unlink1-processes-224 35712.13 ( 0.00%) 36685.96 ( 2.73%)
== 2. ppc64le ==
Avg runtime set_task_state(): 938 msecs
Avg runtime set_current_state: 940 msecs
vanilla dirty
Hmean unlink1-processes-2 19269.19 ( 0.00%) 30704.50 ( 59.35%)
Hmean unlink1-processes-5 20106.15 ( 0.00%) 21804.15 ( 8.45%)
Hmean unlink1-processes-8 17496.97 ( 0.00%) 17243.28 ( -1.45%)
Hmean unlink1-processes-12 14224.15 ( 0.00%) 17240.21 ( 21.20%)
Hmean unlink1-processes-21 14155.66 ( 0.00%) 15681.23 ( 10.78%)
Hmean unlink1-processes-30 14450.70 ( 0.00%) 15995.83 ( 10.69%)
Hmean unlink1-processes-48 16945.57 ( 0.00%) 16370.42 ( -3.39%)
Hmean unlink1-processes-79 15788.39 ( 0.00%) 14639.27 ( -7.28%)
Hmean unlink1-processes-110 14268.48 ( 0.00%) 14377.40 ( 0.76%)
Hmean unlink1-processes-141 14023.65 ( 0.00%) 16271.69 ( 16.03%)
Hmean unlink1-processes-172 13417.62 ( 0.00%) 16067.55 ( 19.75%)
Hmean unlink1-processes-203 15293.08 ( 0.00%) 15440.40 ( 0.96%)
Hmean unlink1-processes-234 13719.32 ( 0.00%) 16190.74 ( 18.01%)
Hmean unlink1-processes-265 16400.97 ( 0.00%) 16115.22 ( -1.74%)
Hmean unlink1-processes-296 14388.60 ( 0.00%) 16216.13 ( 12.70%)
Hmean unlink1-processes-320 15771.85 ( 0.00%) 15905.96 ( 0.85%)
x86-64 (known to be fast for get_current()/this_cpu_read_stable() caching)
and ppc64 (with paca) show similar improvements in the unlink microbenches.
The small delta for ppc64 (2ms), does not represent the gains on the unlink
runs. In the case of x86, there was a decent amount of variation in the
latency runs, but always within a 20 to 50ms increase), ppc was more constant.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dave@stgolabs.net
Cc: mark.rutland@arm.com
Link: http://lkml.kernel.org/r/1483479794-14013-5-git-send-email-dave@stgolabs.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-04 05:43:14 +08:00
|
|
|
__set_current_state(TASK_RUNNING);
|
2015-01-20 09:39:21 +08:00
|
|
|
|
2024-06-11 20:26:44 +08:00
|
|
|
if (ww_ctx) {
|
2018-06-15 16:17:38 +08:00
|
|
|
/*
|
|
|
|
* Wound-Wait; we stole the lock (!first_waiter), check the
|
|
|
|
* waiters as anyone might want to wound us.
|
|
|
|
*/
|
|
|
|
if (!ww_ctx->is_wait_die &&
|
|
|
|
!__mutex_waiter_is_first(lock, &waiter))
|
|
|
|
__ww_mutex_check_waiters(lock, ww_ctx);
|
|
|
|
}
|
|
|
|
|
2024-06-12 13:13:20 +08:00
|
|
|
__mutex_remove_waiter(lock, &waiter);
|
2016-08-23 19:36:04 +08:00
|
|
|
|
2013-06-29 04:13:18 +08:00
|
|
|
debug_mutex_free_waiter(&waiter);
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2013-06-29 04:13:18 +08:00
|
|
|
skip_wait:
|
|
|
|
/* got the lock - cleanup and rejoice! */
|
2008-10-17 05:17:09 +08:00
|
|
|
lock_acquired(&lock->dep_map, ip);
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2024-06-11 20:26:44 +08:00
|
|
|
if (ww_ctx)
|
2018-06-15 16:07:12 +08:00
|
|
|
ww_mutex_lock_acquired(ww, ww_ctx);
|
2013-06-24 16:30:04 +08:00
|
|
|
|
2017-01-17 23:06:09 +08:00
|
|
|
spin_unlock(&lock->wait_lock);
|
2009-01-14 22:36:26 +08:00
|
|
|
preempt_enable();
|
2006-01-10 07:59:19 +08:00
|
|
|
return 0;
|
2013-06-24 16:30:04 +08:00
|
|
|
|
|
|
|
err:
|
sched/core: Remove set_task_state()
This is a nasty interface and setting the state of a foreign task must
not be done. As of the following commit:
be628be0956 ("bcache: Make gc wakeup sane, remove set_task_state()")
... everyone in the kernel calls set_task_state() with current, allowing
the helper to be removed.
However, as the comment indicates, it is still around for those archs
where computing current is more expensive than using a pointer, at least
in theory. An important arch that is affected is arm64, however this has
been addressed now [1] and performance is up to par making no difference
with either calls.
Of all the callers, if any, it's the locking bits that would care most
about this -- ie: we end up passing a tsk pointer to a lot of the lock
slowpath, and setting ->state on that. The following numbers are based
on two tests: a custom ad-hoc microbenchmark that just measures
latencies (for ~65 million calls) between get_task_state() vs
get_current_state().
Secondly for a higher overview, an unlink microbenchmark was used,
which pounds on a single file with open, close,unlink combos with
increasing thread counts (up to 4x ncpus). While the workload is quite
unrealistic, it does contend a lot on the inode mutex or now rwsem.
[1] https://lkml.kernel.org/r/1483468021-8237-1-git-send-email-mark.rutland@arm.com
== 1. x86-64 ==
Avg runtime set_task_state(): 601 msecs
Avg runtime set_current_state(): 552 msecs
vanilla dirty
Hmean unlink1-processes-2 36089.26 ( 0.00%) 38977.33 ( 8.00%)
Hmean unlink1-processes-5 28555.01 ( 0.00%) 29832.55 ( 4.28%)
Hmean unlink1-processes-8 37323.75 ( 0.00%) 44974.57 ( 20.50%)
Hmean unlink1-processes-12 43571.88 ( 0.00%) 44283.01 ( 1.63%)
Hmean unlink1-processes-21 34431.52 ( 0.00%) 38284.45 ( 11.19%)
Hmean unlink1-processes-30 34813.26 ( 0.00%) 37975.17 ( 9.08%)
Hmean unlink1-processes-48 37048.90 ( 0.00%) 39862.78 ( 7.59%)
Hmean unlink1-processes-79 35630.01 ( 0.00%) 36855.30 ( 3.44%)
Hmean unlink1-processes-110 36115.85 ( 0.00%) 39843.91 ( 10.32%)
Hmean unlink1-processes-141 32546.96 ( 0.00%) 35418.52 ( 8.82%)
Hmean unlink1-processes-172 34674.79 ( 0.00%) 36899.21 ( 6.42%)
Hmean unlink1-processes-203 37303.11 ( 0.00%) 36393.04 ( -2.44%)
Hmean unlink1-processes-224 35712.13 ( 0.00%) 36685.96 ( 2.73%)
== 2. ppc64le ==
Avg runtime set_task_state(): 938 msecs
Avg runtime set_current_state: 940 msecs
vanilla dirty
Hmean unlink1-processes-2 19269.19 ( 0.00%) 30704.50 ( 59.35%)
Hmean unlink1-processes-5 20106.15 ( 0.00%) 21804.15 ( 8.45%)
Hmean unlink1-processes-8 17496.97 ( 0.00%) 17243.28 ( -1.45%)
Hmean unlink1-processes-12 14224.15 ( 0.00%) 17240.21 ( 21.20%)
Hmean unlink1-processes-21 14155.66 ( 0.00%) 15681.23 ( 10.78%)
Hmean unlink1-processes-30 14450.70 ( 0.00%) 15995.83 ( 10.69%)
Hmean unlink1-processes-48 16945.57 ( 0.00%) 16370.42 ( -3.39%)
Hmean unlink1-processes-79 15788.39 ( 0.00%) 14639.27 ( -7.28%)
Hmean unlink1-processes-110 14268.48 ( 0.00%) 14377.40 ( 0.76%)
Hmean unlink1-processes-141 14023.65 ( 0.00%) 16271.69 ( 16.03%)
Hmean unlink1-processes-172 13417.62 ( 0.00%) 16067.55 ( 19.75%)
Hmean unlink1-processes-203 15293.08 ( 0.00%) 15440.40 ( 0.96%)
Hmean unlink1-processes-234 13719.32 ( 0.00%) 16190.74 ( 18.01%)
Hmean unlink1-processes-265 16400.97 ( 0.00%) 16115.22 ( -1.74%)
Hmean unlink1-processes-296 14388.60 ( 0.00%) 16216.13 ( 12.70%)
Hmean unlink1-processes-320 15771.85 ( 0.00%) 15905.96 ( 0.85%)
x86-64 (known to be fast for get_current()/this_cpu_read_stable() caching)
and ppc64 (with paca) show similar improvements in the unlink microbenches.
The small delta for ppc64 (2ms), does not represent the gains on the unlink
runs. In the case of x86, there was a decent amount of variation in the
latency runs, but always within a 20 to 50ms increase), ppc was more constant.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dave@stgolabs.net
Cc: mark.rutland@arm.com
Link: http://lkml.kernel.org/r/1483479794-14013-5-git-send-email-dave@stgolabs.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-01-04 05:43:14 +08:00
|
|
|
__set_current_state(TASK_RUNNING);
|
2024-06-12 13:13:20 +08:00
|
|
|
__mutex_remove_waiter(lock, &waiter);
|
2018-06-15 16:07:12 +08:00
|
|
|
err_early_kill:
|
2017-01-17 23:06:09 +08:00
|
|
|
spin_unlock(&lock->wait_lock);
|
2013-06-24 16:30:04 +08:00
|
|
|
debug_mutex_free_waiter(&waiter);
|
|
|
|
mutex_release(&lock->dep_map, 1, ip);
|
|
|
|
preempt_enable();
|
|
|
|
return ret;
|
2006-01-10 07:59:19 +08:00
|
|
|
}
|
|
|
|
|
2016-12-23 17:36:00 +08:00
|
|
|
static int __sched
|
|
|
|
__mutex_lock(struct mutex *lock, long state, unsigned int subclass,
|
|
|
|
struct lockdep_map *nest_lock, unsigned long ip)
|
|
|
|
{
|
|
|
|
return __mutex_lock_common(lock, state, subclass, nest_lock, ip, NULL, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __sched
|
|
|
|
__ww_mutex_lock(struct mutex *lock, long state, unsigned int subclass,
|
|
|
|
struct lockdep_map *nest_lock, unsigned long ip,
|
|
|
|
struct ww_acquire_ctx *ww_ctx)
|
|
|
|
{
|
|
|
|
return __mutex_lock_common(lock, state, subclass, nest_lock, ip, ww_ctx, true);
|
|
|
|
}
|
|
|
|
|
2006-07-03 15:24:55 +08:00
|
|
|
#ifdef CONFIG_DEBUG_LOCK_ALLOC
|
|
|
|
void __sched
|
|
|
|
mutex_lock_nested(struct mutex *lock, unsigned int subclass)
|
|
|
|
{
|
2016-12-23 17:36:00 +08:00
|
|
|
__mutex_lock(lock, TASK_UNINTERRUPTIBLE, subclass, NULL, _RET_IP_);
|
2006-07-03 15:24:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL_GPL(mutex_lock_nested);
|
2006-12-08 18:36:17 +08:00
|
|
|
|
2011-05-25 08:12:03 +08:00
|
|
|
void __sched
|
|
|
|
_mutex_lock_nest_lock(struct mutex *lock, struct lockdep_map *nest)
|
|
|
|
{
|
2016-12-23 17:36:00 +08:00
|
|
|
__mutex_lock(lock, TASK_UNINTERRUPTIBLE, 0, nest, _RET_IP_);
|
2011-05-25 08:12:03 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(_mutex_lock_nest_lock);
|
|
|
|
|
2007-12-07 06:37:59 +08:00
|
|
|
int __sched
|
|
|
|
mutex_lock_killable_nested(struct mutex *lock, unsigned int subclass)
|
|
|
|
{
|
2016-12-23 17:36:00 +08:00
|
|
|
return __mutex_lock(lock, TASK_KILLABLE, subclass, NULL, _RET_IP_);
|
2007-12-07 06:37:59 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mutex_lock_killable_nested);
|
|
|
|
|
2006-12-08 18:36:17 +08:00
|
|
|
int __sched
|
|
|
|
mutex_lock_interruptible_nested(struct mutex *lock, unsigned int subclass)
|
|
|
|
{
|
2016-12-23 17:36:00 +08:00
|
|
|
return __mutex_lock(lock, TASK_INTERRUPTIBLE, subclass, NULL, _RET_IP_);
|
2006-12-08 18:36:17 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mutex_lock_interruptible_nested);
|
2013-06-24 16:30:04 +08:00
|
|
|
|
2016-10-29 00:58:11 +08:00
|
|
|
void __sched
|
|
|
|
mutex_lock_io_nested(struct mutex *lock, unsigned int subclass)
|
|
|
|
{
|
|
|
|
int token;
|
|
|
|
|
|
|
|
might_sleep();
|
|
|
|
|
|
|
|
token = io_schedule_prepare();
|
|
|
|
__mutex_lock_common(lock, TASK_UNINTERRUPTIBLE,
|
|
|
|
subclass, NULL, _RET_IP_, NULL, 0);
|
|
|
|
io_schedule_finish(token);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mutex_lock_io_nested);
|
|
|
|
|
2013-06-20 19:31:17 +08:00
|
|
|
static inline int
|
|
|
|
ww_mutex_deadlock_injection(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
|
|
|
|
unsigned tmp;
|
|
|
|
|
|
|
|
if (ctx->deadlock_inject_countdown-- == 0) {
|
|
|
|
tmp = ctx->deadlock_inject_interval;
|
|
|
|
if (tmp > UINT_MAX/4)
|
|
|
|
tmp = UINT_MAX;
|
|
|
|
else
|
|
|
|
tmp = tmp*2 + tmp + tmp/2;
|
|
|
|
|
|
|
|
ctx->deadlock_inject_interval = tmp;
|
|
|
|
ctx->deadlock_inject_countdown = tmp;
|
|
|
|
ctx->contending_lock = lock;
|
|
|
|
|
|
|
|
ww_mutex_unlock(lock);
|
|
|
|
|
|
|
|
return -EDEADLK;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2013-06-24 16:30:04 +08:00
|
|
|
|
|
|
|
int __sched
|
2016-12-22 02:46:33 +08:00
|
|
|
ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
|
2013-06-24 16:30:04 +08:00
|
|
|
{
|
2013-06-20 19:31:17 +08:00
|
|
|
int ret;
|
|
|
|
|
2013-06-24 16:30:04 +08:00
|
|
|
might_sleep();
|
2016-12-23 17:36:00 +08:00
|
|
|
ret = __ww_mutex_lock(&lock->base, TASK_UNINTERRUPTIBLE,
|
|
|
|
0, ctx ? &ctx->dep_map : NULL, _RET_IP_,
|
|
|
|
ctx);
|
2016-12-22 02:46:32 +08:00
|
|
|
if (!ret && ctx && ctx->acquired > 1)
|
2013-06-20 19:31:17 +08:00
|
|
|
return ww_mutex_deadlock_injection(lock, ctx);
|
|
|
|
|
|
|
|
return ret;
|
2013-06-24 16:30:04 +08:00
|
|
|
}
|
2016-12-22 02:46:33 +08:00
|
|
|
EXPORT_SYMBOL_GPL(ww_mutex_lock);
|
2013-06-24 16:30:04 +08:00
|
|
|
|
|
|
|
int __sched
|
2016-12-22 02:46:33 +08:00
|
|
|
ww_mutex_lock_interruptible(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
|
2013-06-24 16:30:04 +08:00
|
|
|
{
|
2013-06-20 19:31:17 +08:00
|
|
|
int ret;
|
|
|
|
|
2013-06-24 16:30:04 +08:00
|
|
|
might_sleep();
|
2016-12-23 17:36:00 +08:00
|
|
|
ret = __ww_mutex_lock(&lock->base, TASK_INTERRUPTIBLE,
|
|
|
|
0, ctx ? &ctx->dep_map : NULL, _RET_IP_,
|
|
|
|
ctx);
|
2013-06-20 19:31:17 +08:00
|
|
|
|
2016-12-22 02:46:32 +08:00
|
|
|
if (!ret && ctx && ctx->acquired > 1)
|
2013-06-20 19:31:17 +08:00
|
|
|
return ww_mutex_deadlock_injection(lock, ctx);
|
|
|
|
|
|
|
|
return ret;
|
2013-06-24 16:30:04 +08:00
|
|
|
}
|
2016-12-22 02:46:33 +08:00
|
|
|
EXPORT_SYMBOL_GPL(ww_mutex_lock_interruptible);
|
2013-06-24 16:30:04 +08:00
|
|
|
|
2006-07-03 15:24:55 +08:00
|
|
|
#endif
|
|
|
|
|
2006-01-10 07:59:19 +08:00
|
|
|
/*
|
|
|
|
* Release the lock, slowpath:
|
|
|
|
*/
|
2016-08-23 19:36:04 +08:00
|
|
|
static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigned long ip)
|
2006-01-10 07:59:19 +08:00
|
|
|
{
|
2016-08-23 20:40:16 +08:00
|
|
|
struct task_struct *next = NULL;
|
2016-11-18 00:46:38 +08:00
|
|
|
DEFINE_WAKE_Q(wake_q);
|
2017-01-17 23:06:09 +08:00
|
|
|
unsigned long owner;
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2016-08-23 19:36:04 +08:00
|
|
|
mutex_release(&lock->dep_map, 1, ip);
|
|
|
|
|
2006-01-10 07:59:19 +08:00
|
|
|
/*
|
2016-08-23 20:40:16 +08:00
|
|
|
* Release the lock before (potentially) taking the spinlock such that
|
|
|
|
* other contenders can get on with things ASAP.
|
|
|
|
*
|
|
|
|
* Except when HANDOFF, in that case we must not clear the owner field,
|
|
|
|
* but instead set it to the top waiter.
|
2006-01-10 07:59:19 +08:00
|
|
|
*/
|
2016-08-23 20:40:16 +08:00
|
|
|
owner = atomic_long_read(&lock->owner);
|
|
|
|
for (;;) {
|
|
|
|
unsigned long old;
|
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
|
|
|
DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current);
|
2017-01-11 21:17:48 +08:00
|
|
|
DEBUG_LOCKS_WARN_ON(owner & MUTEX_FLAG_PICKUP);
|
2016-08-23 20:40:16 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
if (owner & MUTEX_FLAG_HANDOFF)
|
|
|
|
break;
|
|
|
|
|
|
|
|
old = atomic_long_cmpxchg_release(&lock->owner, owner,
|
|
|
|
__owner_flags(owner));
|
|
|
|
if (old == owner) {
|
|
|
|
if (owner & MUTEX_FLAG_WAITERS)
|
|
|
|
break;
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
owner = old;
|
|
|
|
}
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2017-01-17 23:06:09 +08:00
|
|
|
spin_lock(&lock->wait_lock);
|
2014-01-29 03:13:14 +08:00
|
|
|
debug_mutex_unlock(lock);
|
2006-01-10 07:59:19 +08:00
|
|
|
if (!list_empty(&lock->wait_list)) {
|
|
|
|
/* get the first entry from the wait-list: */
|
|
|
|
struct mutex_waiter *waiter =
|
2016-08-23 20:40:16 +08:00
|
|
|
list_first_entry(&lock->wait_list,
|
|
|
|
struct mutex_waiter, list);
|
|
|
|
|
|
|
|
next = waiter->task;
|
2006-01-10 07:59:19 +08:00
|
|
|
|
|
|
|
debug_mutex_wake_waiter(lock, waiter);
|
2016-08-23 20:40:16 +08:00
|
|
|
wake_q_add(&wake_q, next);
|
2006-01-10 07:59:19 +08:00
|
|
|
}
|
|
|
|
|
2016-08-23 20:40:16 +08:00
|
|
|
if (owner & MUTEX_FLAG_HANDOFF)
|
|
|
|
__mutex_handoff(lock, next);
|
|
|
|
|
2017-01-17 23:06:09 +08:00
|
|
|
spin_unlock(&lock->wait_lock);
|
2016-08-23 20:40:16 +08:00
|
|
|
|
2016-01-25 10:23:43 +08:00
|
|
|
wake_up_q(&wake_q);
|
2006-01-10 07:59:19 +08:00
|
|
|
}
|
|
|
|
|
2007-10-12 04:11:12 +08:00
|
|
|
#ifndef CONFIG_DEBUG_LOCK_ALLOC
|
2006-01-10 07:59:19 +08:00
|
|
|
/*
|
|
|
|
* Here come the less common (and hence less performance-critical) APIs:
|
|
|
|
* mutex_lock_interruptible() and mutex_trylock().
|
|
|
|
*/
|
2008-02-08 20:19:53 +08:00
|
|
|
static noinline int __sched
|
2013-06-20 19:31:05 +08:00
|
|
|
__mutex_lock_killable_slowpath(struct mutex *lock);
|
2007-12-07 06:37:59 +08:00
|
|
|
|
2008-02-08 20:19:53 +08:00
|
|
|
static noinline int __sched
|
2013-06-20 19:31:05 +08:00
|
|
|
__mutex_lock_interruptible_slowpath(struct mutex *lock);
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2010-09-03 06:48:16 +08:00
|
|
|
/**
|
2018-03-15 19:58:12 +08:00
|
|
|
* mutex_lock_interruptible() - Acquire the mutex, interruptible by signals.
|
|
|
|
* @lock: The mutex to be acquired.
|
2006-01-10 07:59:19 +08:00
|
|
|
*
|
2018-03-15 19:58:12 +08:00
|
|
|
* Lock the mutex like mutex_lock(). If a signal is delivered while the
|
|
|
|
* process is sleeping, this function will return without acquiring the
|
|
|
|
* mutex.
|
2006-01-10 07:59:19 +08:00
|
|
|
*
|
2018-03-15 19:58:12 +08:00
|
|
|
* Context: Process context.
|
|
|
|
* Return: 0 if the lock was successfully acquired or %-EINTR if a
|
|
|
|
* signal arrived.
|
2006-01-10 07:59:19 +08:00
|
|
|
*/
|
2008-02-08 20:19:53 +08:00
|
|
|
int __sched mutex_lock_interruptible(struct mutex *lock)
|
2006-01-10 07:59:19 +08:00
|
|
|
{
|
2006-01-11 05:10:36 +08:00
|
|
|
might_sleep();
|
2016-08-23 19:36:04 +08:00
|
|
|
|
|
|
|
if (__mutex_trylock_fast(lock))
|
2013-06-20 19:31:05 +08:00
|
|
|
return 0;
|
2016-08-23 19:36:04 +08:00
|
|
|
|
|
|
|
return __mutex_lock_interruptible_slowpath(lock);
|
2006-01-10 07:59:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL(mutex_lock_interruptible);
|
|
|
|
|
2018-03-15 19:58:12 +08:00
|
|
|
/**
|
|
|
|
* mutex_lock_killable() - Acquire the mutex, interruptible by fatal signals.
|
|
|
|
* @lock: The mutex to be acquired.
|
|
|
|
*
|
|
|
|
* Lock the mutex like mutex_lock(). If a signal which will be fatal to
|
|
|
|
* the current process is delivered while the process is sleeping, this
|
|
|
|
* function will return without acquiring the mutex.
|
|
|
|
*
|
|
|
|
* Context: Process context.
|
|
|
|
* Return: 0 if the lock was successfully acquired or %-EINTR if a
|
|
|
|
* fatal signal arrived.
|
|
|
|
*/
|
2008-02-08 20:19:53 +08:00
|
|
|
int __sched mutex_lock_killable(struct mutex *lock)
|
2007-12-07 06:37:59 +08:00
|
|
|
{
|
|
|
|
might_sleep();
|
2016-08-23 19:36:04 +08:00
|
|
|
|
|
|
|
if (__mutex_trylock_fast(lock))
|
2013-06-20 19:31:05 +08:00
|
|
|
return 0;
|
2016-08-23 19:36:04 +08:00
|
|
|
|
|
|
|
return __mutex_lock_killable_slowpath(lock);
|
2007-12-07 06:37:59 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mutex_lock_killable);
|
|
|
|
|
2018-03-15 19:58:12 +08:00
|
|
|
/**
|
|
|
|
* mutex_lock_io() - Acquire the mutex and mark the process as waiting for I/O
|
|
|
|
* @lock: The mutex to be acquired.
|
|
|
|
*
|
|
|
|
* Lock the mutex like mutex_lock(). While the task is waiting for this
|
|
|
|
* mutex, it will be accounted as being in the IO wait state by the
|
|
|
|
* scheduler.
|
|
|
|
*
|
|
|
|
* Context: Process context.
|
|
|
|
*/
|
2016-10-29 00:58:11 +08:00
|
|
|
void __sched mutex_lock_io(struct mutex *lock)
|
|
|
|
{
|
|
|
|
int token;
|
|
|
|
|
|
|
|
token = io_schedule_prepare();
|
|
|
|
mutex_lock(lock);
|
|
|
|
io_schedule_finish(token);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mutex_lock_io);
|
|
|
|
|
2016-08-23 19:36:04 +08:00
|
|
|
static noinline void __sched
|
|
|
|
__mutex_lock_slowpath(struct mutex *lock)
|
2007-10-12 04:11:12 +08:00
|
|
|
{
|
2016-12-23 17:36:00 +08:00
|
|
|
__mutex_lock(lock, TASK_UNINTERRUPTIBLE, 0, NULL, _RET_IP_);
|
2007-10-12 04:11:12 +08:00
|
|
|
}
|
|
|
|
|
2008-02-08 20:19:53 +08:00
|
|
|
static noinline int __sched
|
2013-06-20 19:31:05 +08:00
|
|
|
__mutex_lock_killable_slowpath(struct mutex *lock)
|
2007-12-07 06:37:59 +08:00
|
|
|
{
|
2016-12-23 17:36:00 +08:00
|
|
|
return __mutex_lock(lock, TASK_KILLABLE, 0, NULL, _RET_IP_);
|
2007-12-07 06:37:59 +08:00
|
|
|
}
|
|
|
|
|
2008-02-08 20:19:53 +08:00
|
|
|
static noinline int __sched
|
2013-06-20 19:31:05 +08:00
|
|
|
__mutex_lock_interruptible_slowpath(struct mutex *lock)
|
2006-01-10 07:59:19 +08:00
|
|
|
{
|
2016-12-23 17:36:00 +08:00
|
|
|
return __mutex_lock(lock, TASK_INTERRUPTIBLE, 0, NULL, _RET_IP_);
|
2013-06-24 16:30:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static noinline int __sched
|
|
|
|
__ww_mutex_lock_slowpath(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
|
|
|
|
{
|
2016-12-23 17:36:00 +08:00
|
|
|
return __ww_mutex_lock(&lock->base, TASK_UNINTERRUPTIBLE, 0, NULL,
|
|
|
|
_RET_IP_, ctx);
|
2006-01-10 07:59:19 +08:00
|
|
|
}
|
2013-06-24 16:30:04 +08:00
|
|
|
|
|
|
|
static noinline int __sched
|
|
|
|
__ww_mutex_lock_interruptible_slowpath(struct ww_mutex *lock,
|
|
|
|
struct ww_acquire_ctx *ctx)
|
|
|
|
{
|
2016-12-23 17:36:00 +08:00
|
|
|
return __ww_mutex_lock(&lock->base, TASK_INTERRUPTIBLE, 0, NULL,
|
|
|
|
_RET_IP_, ctx);
|
2013-06-24 16:30:04 +08:00
|
|
|
}
|
|
|
|
|
2007-10-12 04:11:12 +08:00
|
|
|
#endif
|
2006-01-10 07:59:19 +08:00
|
|
|
|
2010-09-03 06:48:16 +08:00
|
|
|
/**
|
|
|
|
* mutex_trylock - try to acquire the mutex, without waiting
|
2006-01-10 07:59:19 +08:00
|
|
|
* @lock: the mutex to be acquired
|
|
|
|
*
|
|
|
|
* Try to acquire the mutex atomically. Returns 1 if the mutex
|
|
|
|
* has been acquired successfully, and 0 on contention.
|
|
|
|
*
|
|
|
|
* NOTE: this function follows the spin_trylock() convention, so
|
2010-09-03 06:48:16 +08:00
|
|
|
* it is negated from the down_trylock() return values! Be careful
|
2006-01-10 07:59:19 +08:00
|
|
|
* about this when converting semaphore users to mutexes.
|
|
|
|
*
|
|
|
|
* This function must not be used in interrupt context. The
|
|
|
|
* mutex must be released by the same task that acquired it.
|
|
|
|
*/
|
2008-02-08 20:19:53 +08:00
|
|
|
int __sched mutex_trylock(struct mutex *lock)
|
2006-01-10 07:59:19 +08:00
|
|
|
{
|
2019-07-03 17:21:26 +08:00
|
|
|
bool locked;
|
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
|
|
|
DEBUG_LOCKS_WARN_ON(lock->magic != lock);
|
|
|
|
#endif
|
2009-01-12 21:01:47 +08:00
|
|
|
|
2019-07-03 17:21:26 +08:00
|
|
|
locked = __mutex_trylock(lock);
|
2016-08-23 19:36:04 +08:00
|
|
|
if (locked)
|
|
|
|
mutex_acquire(&lock->dep_map, 0, 1, _RET_IP_);
|
2009-01-12 21:01:47 +08:00
|
|
|
|
2016-08-23 19:36:04 +08:00
|
|
|
return locked;
|
2006-01-10 07:59:19 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mutex_trylock);
|
2009-04-30 06:59:58 +08:00
|
|
|
|
2013-06-24 16:30:04 +08:00
|
|
|
#ifndef CONFIG_DEBUG_LOCK_ALLOC
|
|
|
|
int __sched
|
2016-12-22 02:46:33 +08:00
|
|
|
ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
|
2013-06-24 16:30:04 +08:00
|
|
|
{
|
|
|
|
might_sleep();
|
|
|
|
|
2016-08-23 19:36:04 +08:00
|
|
|
if (__mutex_trylock_fast(&lock->base)) {
|
2016-12-22 02:46:32 +08:00
|
|
|
if (ctx)
|
|
|
|
ww_mutex_set_context_fastpath(lock, ctx);
|
2016-08-23 19:36:04 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return __ww_mutex_lock_slowpath(lock, ctx);
|
2013-06-24 16:30:04 +08:00
|
|
|
}
|
2016-12-22 02:46:33 +08:00
|
|
|
EXPORT_SYMBOL(ww_mutex_lock);
|
2013-06-24 16:30:04 +08:00
|
|
|
|
|
|
|
int __sched
|
2016-12-22 02:46:33 +08:00
|
|
|
ww_mutex_lock_interruptible(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
|
2013-06-24 16:30:04 +08:00
|
|
|
{
|
|
|
|
might_sleep();
|
|
|
|
|
2016-08-23 19:36:04 +08:00
|
|
|
if (__mutex_trylock_fast(&lock->base)) {
|
2016-12-22 02:46:32 +08:00
|
|
|
if (ctx)
|
|
|
|
ww_mutex_set_context_fastpath(lock, ctx);
|
2016-08-23 19:36:04 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return __ww_mutex_lock_interruptible_slowpath(lock, ctx);
|
2013-06-24 16:30:04 +08:00
|
|
|
}
|
2016-12-22 02:46:33 +08:00
|
|
|
EXPORT_SYMBOL(ww_mutex_lock_interruptible);
|
2013-06-24 16:30:04 +08:00
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2009-04-30 06:59:58 +08:00
|
|
|
/**
|
|
|
|
* atomic_dec_and_mutex_lock - return holding mutex if we dec to 0
|
|
|
|
* @cnt: the atomic which we are to dec
|
|
|
|
* @lock: the mutex to return holding if we dec to 0
|
|
|
|
*
|
|
|
|
* return true and hold lock if we dec to 0, return false otherwise
|
|
|
|
*/
|
|
|
|
int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock)
|
|
|
|
{
|
|
|
|
/* dec if we can't possibly hit 0 */
|
|
|
|
if (atomic_add_unless(cnt, -1, 1))
|
|
|
|
return 0;
|
|
|
|
/* we might hit 0, so take the lock */
|
|
|
|
mutex_lock(lock);
|
|
|
|
if (!atomic_dec_and_test(cnt)) {
|
|
|
|
/* when we actually did the dec, we didn't hit 0 */
|
|
|
|
mutex_unlock(lock);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
/* we hit 0, and we hold the lock */
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(atomic_dec_and_mutex_lock);
|