2019-05-19 15:08:55 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2006-01-10 02:59:19 +03:00
|
|
|
/*
|
2013-11-08 11:26:39 +04:00
|
|
|
* kernel/locking/mutex.c
|
2006-01-10 02:59:19 +03: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 16:01:47 +03: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 14:32:41 +03:00
|
|
|
* Also see Documentation/locking/mutex-design.rst.
|
2006-01-10 02:59:19 +03:00
|
|
|
*/
|
|
|
|
#include <linux/mutex.h>
|
2013-07-05 11:29:32 +04:00
|
|
|
#include <linux/ww_mutex.h>
|
2017-02-02 21:15:33 +03:00
|
|
|
#include <linux/sched/signal.h>
|
2013-02-07 19:47:07 +04:00
|
|
|
#include <linux/sched/rt.h>
|
2017-02-01 18:36:40 +03:00
|
|
|
#include <linux/sched/wake_q.h>
|
2017-02-08 20:51:35 +03:00
|
|
|
#include <linux/sched/debug.h>
|
2011-05-23 22:51:41 +04:00
|
|
|
#include <linux/export.h>
|
2006-01-10 02:59:19 +03:00
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/interrupt.h>
|
2006-07-03 11:24:33 +04:00
|
|
|
#include <linux/debug_locks.h>
|
2015-01-30 12:14:25 +03:00
|
|
|
#include <linux/osq_lock.h>
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2021-08-16 00:29:01 +03:00
|
|
|
#ifndef CONFIG_PREEMPT_RT
|
2021-08-17 17:17:38 +03:00
|
|
|
#include "mutex.h"
|
|
|
|
|
2006-01-10 02:59:19 +03:00
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
2021-06-30 18:35:20 +03:00
|
|
|
# define MUTEX_WARN_ON(cond) DEBUG_LOCKS_WARN_ON(cond)
|
2006-01-10 02:59:19 +03:00
|
|
|
#else
|
2021-06-30 18:35:20 +03:00
|
|
|
# define MUTEX_WARN_ON(cond)
|
2006-01-10 02:59:19 +03:00
|
|
|
#endif
|
|
|
|
|
2006-07-03 11:24:55 +04:00
|
|
|
void
|
|
|
|
__mutex_init(struct mutex *lock, const char *name, struct lock_class_key *key)
|
2006-01-10 02:59:19 +03:00
|
|
|
{
|
2016-08-23 14:36:04 +03:00
|
|
|
atomic_long_set(&lock->owner, 0);
|
2021-08-16 00:28:36 +03:00
|
|
|
raw_spin_lock_init(&lock->wait_lock);
|
2006-01-10 02:59:19 +03:00
|
|
|
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-17 23:23:13 +04:00
|
|
|
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
|
2014-07-14 21:27:50 +04: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-17 23:23:13 +04:00
|
|
|
#endif
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2006-07-03 11:24:55 +04:00
|
|
|
debug_mutex_init(lock, name, key);
|
2006-01-10 02:59:19 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__mutex_init);
|
|
|
|
|
2016-08-23 14:36:04 +03: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 16:17:48 +03:00
|
|
|
* at least L1_CACHE_BYTES, we have low bits to store extra state.
|
2016-08-23 14:36:04 +03:00
|
|
|
*
|
|
|
|
* Bit0 indicates a non-empty waiter list; unlock must issue a wakeup.
|
2016-08-23 15:40:16 +03:00
|
|
|
* Bit1 indicates unlock needs to hand the lock to the top-waiter
|
2017-01-11 16:17:48 +03:00
|
|
|
* Bit2 indicates handoff has been done and we're waiting for pickup.
|
2016-08-23 14:36:04 +03:00
|
|
|
*/
|
|
|
|
#define MUTEX_FLAG_WAITERS 0x01
|
2016-08-23 15:40:16 +03:00
|
|
|
#define MUTEX_FLAG_HANDOFF 0x02
|
2017-01-11 16:17:48 +03:00
|
|
|
#define MUTEX_FLAG_PICKUP 0x04
|
2016-08-23 14:36:04 +03:00
|
|
|
|
2017-01-11 16:17:48 +03:00
|
|
|
#define MUTEX_FLAGS 0x07
|
2016-08-23 14:36:04 +03:00
|
|
|
|
2019-07-31 18:05:03 +03: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 18:05:04 +03:00
|
|
|
return (struct task_struct *)(atomic_long_read(&lock->owner) & ~MUTEX_FLAGS);
|
2019-07-31 18:05:03 +03:00
|
|
|
}
|
|
|
|
|
2016-08-23 14:36:04 +03:00
|
|
|
static inline struct task_struct *__owner_task(unsigned long owner)
|
|
|
|
{
|
|
|
|
return (struct task_struct *)(owner & ~MUTEX_FLAGS);
|
|
|
|
}
|
|
|
|
|
2019-07-31 18:05:03 +03:00
|
|
|
bool mutex_is_locked(struct mutex *lock)
|
|
|
|
{
|
|
|
|
return __mutex_owner(lock) != NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mutex_is_locked);
|
|
|
|
|
2016-08-23 14:36:04 +03:00
|
|
|
static inline unsigned long __owner_flags(unsigned long owner)
|
|
|
|
{
|
|
|
|
return owner & MUTEX_FLAGS;
|
|
|
|
}
|
|
|
|
|
2021-06-30 18:35:19 +03:00
|
|
|
static inline struct task_struct *__mutex_trylock_common(struct mutex *lock, bool handoff)
|
2016-08-23 14:36:04 +03:00
|
|
|
{
|
|
|
|
unsigned long owner, curr = (unsigned long)current;
|
|
|
|
|
|
|
|
owner = atomic_long_read(&lock->owner);
|
|
|
|
for (;;) { /* must loop, can race against a flag */
|
2021-06-30 18:35:17 +03:00
|
|
|
unsigned long flags = __owner_flags(owner);
|
2017-01-11 16:17:48 +03:00
|
|
|
unsigned long task = owner & ~MUTEX_FLAGS;
|
2016-08-23 15:40:16 +03:00
|
|
|
|
2017-01-11 16:17:48 +03:00
|
|
|
if (task) {
|
2021-06-30 18:35:19 +03:00
|
|
|
if (flags & MUTEX_FLAG_PICKUP) {
|
|
|
|
if (task != curr)
|
|
|
|
break;
|
|
|
|
flags &= ~MUTEX_FLAG_PICKUP;
|
|
|
|
} else if (handoff) {
|
|
|
|
if (flags & MUTEX_FLAG_HANDOFF)
|
|
|
|
break;
|
|
|
|
flags |= MUTEX_FLAG_HANDOFF;
|
|
|
|
} else {
|
2017-01-11 16:17:48 +03:00
|
|
|
break;
|
2021-06-30 18:35:19 +03:00
|
|
|
}
|
2017-01-11 16:17:48 +03:00
|
|
|
} else {
|
2021-06-30 18:35:20 +03:00
|
|
|
MUTEX_WARN_ON(flags & (MUTEX_FLAG_HANDOFF | MUTEX_FLAG_PICKUP));
|
2021-06-30 18:35:19 +03:00
|
|
|
task = curr;
|
2016-08-23 15:40:16 +03:00
|
|
|
}
|
|
|
|
|
2021-06-30 18:35:19 +03:00
|
|
|
if (atomic_long_try_cmpxchg_acquire(&lock->owner, &owner, task | flags)) {
|
|
|
|
if (task == curr)
|
|
|
|
return NULL;
|
|
|
|
break;
|
|
|
|
}
|
2016-08-23 14:36:04 +03:00
|
|
|
}
|
2017-01-11 16:17:48 +03:00
|
|
|
|
|
|
|
return __owner_task(owner);
|
|
|
|
}
|
|
|
|
|
2021-06-30 18:35:19 +03:00
|
|
|
/*
|
|
|
|
* Trylock or set HANDOFF
|
|
|
|
*/
|
|
|
|
static inline bool __mutex_trylock_or_handoff(struct mutex *lock, bool handoff)
|
|
|
|
{
|
|
|
|
return !__mutex_trylock_common(lock, handoff);
|
|
|
|
}
|
|
|
|
|
2017-01-11 16:17:48 +03:00
|
|
|
/*
|
|
|
|
* Actual trylock that will work on any unlocked state.
|
|
|
|
*/
|
|
|
|
static inline bool __mutex_trylock(struct mutex *lock)
|
|
|
|
{
|
2021-06-30 18:35:19 +03:00
|
|
|
return !__mutex_trylock_common(lock, false);
|
2016-08-23 14:36:04 +03: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 12:05:35 +03:00
|
|
|
unsigned long zero = 0UL;
|
2016-08-23 14:36:04 +03: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 12:05:35 +03:00
|
|
|
if (atomic_long_try_cmpxchg_acquire(&lock->owner, &zero, curr))
|
2016-08-23 14:36:04 +03:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static __always_inline bool __mutex_unlock_fast(struct mutex *lock)
|
|
|
|
{
|
|
|
|
unsigned long curr = (unsigned long)current;
|
|
|
|
|
2021-06-30 18:35:17 +03:00
|
|
|
return atomic_long_try_cmpxchg_release(&lock->owner, &curr, 0UL);
|
2016-08-23 14:36:04 +03:00
|
|
|
}
|
|
|
|
#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 15:40:16 +03: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 11:17:38 +03:00
|
|
|
/*
|
|
|
|
* Add @waiter to a given location in the lock wait_list and set the
|
|
|
|
* FLAG_WAITERS flag if it's the first waiter.
|
|
|
|
*/
|
2021-05-17 06:40:05 +03:00
|
|
|
static void
|
2018-06-15 11:17:38 +03: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);
|
|
|
|
}
|
|
|
|
|
2021-05-17 06:40:05 +03: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 15:40:16 +03:00
|
|
|
/*
|
|
|
|
* Give up ownership to a specific task, when @task = NULL, this is equivalent
|
2021-03-22 04:35:05 +03:00
|
|
|
* to a regular unlock. Sets PICKUP on a handoff, clears HANDOFF, preserves
|
2017-01-11 16:17:48 +03:00
|
|
|
* WAITERS. Provides RELEASE semantics like a regular unlock, the
|
|
|
|
* __mutex_trylock() provides a matching ACQUIRE semantics for the handoff.
|
2016-08-23 15:40:16 +03:00
|
|
|
*/
|
|
|
|
static void __mutex_handoff(struct mutex *lock, struct task_struct *task)
|
|
|
|
{
|
|
|
|
unsigned long owner = atomic_long_read(&lock->owner);
|
|
|
|
|
|
|
|
for (;;) {
|
2021-06-30 18:35:17 +03:00
|
|
|
unsigned long new;
|
2016-08-23 15:40:16 +03:00
|
|
|
|
2021-06-30 18:35:20 +03:00
|
|
|
MUTEX_WARN_ON(__owner_task(owner) != current);
|
|
|
|
MUTEX_WARN_ON(owner & MUTEX_FLAG_PICKUP);
|
2016-08-23 15:40:16 +03:00
|
|
|
|
|
|
|
new = (owner & MUTEX_FLAG_WAITERS);
|
|
|
|
new |= (unsigned long)task;
|
2017-01-11 16:17:48 +03:00
|
|
|
if (task)
|
|
|
|
new |= MUTEX_FLAG_PICKUP;
|
2016-08-23 15:40:16 +03:00
|
|
|
|
2021-06-30 18:35:17 +03:00
|
|
|
if (atomic_long_try_cmpxchg_release(&lock->owner, &owner, new))
|
2016-08-23 15:40:16 +03:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-10-12 00:11:12 +04:00
|
|
|
#ifndef CONFIG_DEBUG_LOCK_ALLOC
|
2006-01-10 02:59:19 +03: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 14:36:04 +03:00
|
|
|
static void __sched __mutex_lock_slowpath(struct mutex *lock);
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2010-09-03 02:48:16 +04:00
|
|
|
/**
|
2006-01-10 02:59:19 +03: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 00:47:32 +03:00
|
|
|
* memory where the mutex resides must not be freed with
|
2006-01-10 02:59:19 +03: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 16:17:45 +03: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 02:59:19 +03:00
|
|
|
*
|
|
|
|
* This function is similar to (but not equivalent to) down().
|
|
|
|
*/
|
2009-04-02 04:21:56 +04:00
|
|
|
void __sched mutex_lock(struct mutex *lock)
|
2006-01-10 02:59:19 +03:00
|
|
|
{
|
2006-01-11 00:10:36 +03:00
|
|
|
might_sleep();
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2016-08-23 14:36:04 +03:00
|
|
|
if (!__mutex_trylock_fast(lock))
|
|
|
|
__mutex_lock_slowpath(lock);
|
|
|
|
}
|
2006-01-10 02:59:19 +03:00
|
|
|
EXPORT_SYMBOL(mutex_lock);
|
2007-10-12 00:11:12 +04:00
|
|
|
#endif
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2021-08-17 17:31:54 +03:00
|
|
|
#include "ww_mutex.h"
|
2014-07-31 00:41:53 +04:00
|
|
|
|
2013-04-17 23:23:11 +04:00
|
|
|
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
|
2016-12-21 21:46:38 +03:00
|
|
|
|
2021-06-30 18:35:19 +03:00
|
|
|
/*
|
|
|
|
* Trylock variant that returns the owning task on failure.
|
|
|
|
*/
|
|
|
|
static inline struct task_struct *__mutex_trylock_or_owner(struct mutex *lock)
|
|
|
|
{
|
|
|
|
return __mutex_trylock_common(lock, false);
|
|
|
|
}
|
|
|
|
|
2016-12-21 21:46:38 +03: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-06 22:45:06 +03:00
|
|
|
|
|
|
|
/*
|
2016-12-21 21:46:38 +03: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-06 22:45:06 +03:00
|
|
|
*/
|
2016-12-21 21:46:38 +03: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-06 22:45:06 +03:00
|
|
|
}
|
2014-07-31 00:41:53 +04:00
|
|
|
|
2013-04-17 23:23:11 +04:00
|
|
|
/*
|
2016-12-21 21:46:37 +03: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-17 23:23:11 +04:00
|
|
|
*/
|
|
|
|
static noinline
|
2016-12-21 21:46:37 +03:00
|
|
|
bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner,
|
2016-12-21 21:46:38 +03:00
|
|
|
struct ww_acquire_ctx *ww_ctx, struct mutex_waiter *waiter)
|
2013-04-17 23:23:11 +04:00
|
|
|
{
|
2015-04-08 22:39:19 +03:00
|
|
|
bool ret = true;
|
2015-02-03 00:59:27 +03:00
|
|
|
|
2013-04-17 23:23:11 +04:00
|
|
|
rcu_read_lock();
|
2016-08-23 14:36:04 +03:00
|
|
|
while (__mutex_owner(lock) == owner) {
|
2015-02-03 00:59:27 +03:00
|
|
|
/*
|
|
|
|
* Ensure we emit the owner->on_cpu, dereference _after_
|
2015-04-08 22:39:19 +03:00
|
|
|
* checking lock->owner still matches owner. If that fails,
|
|
|
|
* owner might point to freed memory. If it still matches,
|
2015-02-03 00:59:27 +03:00
|
|
|
* the rcu_read_lock() ensures the memory stays valid.
|
|
|
|
*/
|
|
|
|
barrier();
|
|
|
|
|
2016-11-02 12:08:30 +03: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 00:59:27 +03:00
|
|
|
ret = false;
|
|
|
|
break;
|
|
|
|
}
|
2013-04-17 23:23:11 +04:00
|
|
|
|
2016-12-21 21:46:38 +03:00
|
|
|
if (ww_ctx && !ww_mutex_spin_on_owner(lock, ww_ctx, waiter)) {
|
|
|
|
ret = false;
|
|
|
|
break;
|
2016-12-21 21:46:37 +03:00
|
|
|
}
|
|
|
|
|
2016-10-25 12:03:14 +03:00
|
|
|
cpu_relax();
|
2013-04-17 23:23:11 +04:00
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
2015-02-03 00:59:27 +03:00
|
|
|
return ret;
|
2013-04-17 23:23:11 +04: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-17 23:23:13 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Initial check for entering the mutex spinning loop
|
|
|
|
*/
|
|
|
|
static inline int mutex_can_spin_on_owner(struct mutex *lock)
|
|
|
|
{
|
2013-07-19 22:31:01 +04: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-17 23:23:13 +04:00
|
|
|
int retval = 1;
|
|
|
|
|
2014-01-28 23:13:12 +04: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-17 23:23:13 +04:00
|
|
|
rcu_read_lock();
|
2016-08-23 14:36:04 +03:00
|
|
|
owner = __mutex_owner(lock);
|
2016-11-02 12:08:30 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* As lock holder preemption issue, we both skip spinning if task is not
|
|
|
|
* on cpu or its cpu is preempted
|
|
|
|
*/
|
2013-07-19 22:31:01 +04:00
|
|
|
if (owner)
|
2016-11-02 12:08:30 +03: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-17 23:23:13 +04:00
|
|
|
rcu_read_unlock();
|
2016-08-23 14:36:04 +03: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-17 23:23:13 +04:00
|
|
|
/*
|
2016-08-23 14:36:04 +03: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-17 23:23:13 +04:00
|
|
|
*/
|
|
|
|
return retval;
|
|
|
|
}
|
2014-07-31 00:41:53 +04: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 02:35:09 +03: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 00:41:53 +04:00
|
|
|
*/
|
2016-12-23 12:36:00 +03:00
|
|
|
static __always_inline bool
|
|
|
|
mutex_optimistic_spin(struct mutex *lock, struct ww_acquire_ctx *ww_ctx,
|
2021-03-16 18:31:16 +03:00
|
|
|
struct mutex_waiter *waiter)
|
2014-07-31 00:41:53 +04:00
|
|
|
{
|
2016-08-27 02:35:09 +03: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 00:41:53 +04:00
|
|
|
|
2016-08-27 02:35:09 +03: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 00:41:53 +04:00
|
|
|
|
2016-08-27 02:35:09 +03:00
|
|
|
for (;;) {
|
2014-07-31 00:41:53 +04:00
|
|
|
struct task_struct *owner;
|
|
|
|
|
2017-01-11 16:17:48 +03:00
|
|
|
/* Try to acquire the mutex... */
|
|
|
|
owner = __mutex_trylock_or_owner(lock);
|
|
|
|
if (!owner)
|
|
|
|
break;
|
2014-07-31 00:41:53 +04:00
|
|
|
|
|
|
|
/*
|
2017-01-11 16:17:48 +03:00
|
|
|
* There's an owner, wait for it to either
|
2014-07-31 00:41:53 +04:00
|
|
|
* release the lock or go to sleep.
|
|
|
|
*/
|
2016-12-21 21:46:38 +03:00
|
|
|
if (!mutex_spin_on_owner(lock, owner, ww_ctx, waiter))
|
2017-01-11 16:17:48 +03:00
|
|
|
goto fail_unlock;
|
2016-08-27 02:35:09 +03:00
|
|
|
|
2014-07-31 00:41:53 +04: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 12:03:14 +03:00
|
|
|
cpu_relax();
|
2014-07-31 00:41:53 +04:00
|
|
|
}
|
|
|
|
|
2016-08-27 02:35:09 +03:00
|
|
|
if (!waiter)
|
|
|
|
osq_unlock(&lock->osq);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
|
|
fail_unlock:
|
|
|
|
if (!waiter)
|
|
|
|
osq_unlock(&lock->osq);
|
|
|
|
|
|
|
|
fail:
|
2014-07-31 00:41:53 +04: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 12:18:46 +04: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 00:41:53 +04:00
|
|
|
schedule_preempt_disabled();
|
2014-09-24 12:18:46 +04:00
|
|
|
}
|
2014-07-31 00:41:53 +04:00
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#else
|
2016-12-23 12:36:00 +03:00
|
|
|
static __always_inline bool
|
|
|
|
mutex_optimistic_spin(struct mutex *lock, struct ww_acquire_ctx *ww_ctx,
|
2021-03-16 18:31:16 +03:00
|
|
|
struct mutex_waiter *waiter)
|
2014-07-31 00:41:53 +04:00
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
2013-04-17 23:23:11 +04:00
|
|
|
#endif
|
|
|
|
|
2016-08-23 14:36:04 +03:00
|
|
|
static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigned long ip);
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2010-09-03 02:48:16 +04:00
|
|
|
/**
|
2006-01-10 02:59:19 +03: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 15:19:53 +03:00
|
|
|
void __sched mutex_unlock(struct mutex *lock)
|
2006-01-10 02:59:19 +03:00
|
|
|
{
|
2016-08-23 14:36:04 +03:00
|
|
|
#ifndef CONFIG_DEBUG_LOCK_ALLOC
|
|
|
|
if (__mutex_unlock_fast(lock))
|
|
|
|
return;
|
2009-01-12 16:01:47 +03:00
|
|
|
#endif
|
2016-08-23 14:36:04 +03:00
|
|
|
__mutex_unlock_slowpath(lock, _RET_IP_);
|
2006-01-10 02:59:19 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mutex_unlock);
|
|
|
|
|
2013-06-24 12:30:04 +04: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)
|
|
|
|
{
|
2021-08-17 17:19:04 +03:00
|
|
|
__ww_mutex_unlock(lock);
|
2016-08-23 14:36:04 +03:00
|
|
|
mutex_unlock(&lock->base);
|
2013-06-24 12:30:04 +04:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ww_mutex_unlock);
|
|
|
|
|
2006-01-10 02:59:19 +03:00
|
|
|
/*
|
|
|
|
* Lock a mutex (possibly interruptible), slowpath:
|
|
|
|
*/
|
2013-06-24 12:30:04 +04:00
|
|
|
static __always_inline int __sched
|
2021-06-11 11:28:17 +03:00
|
|
|
__mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclass,
|
2013-06-24 12:30:04 +04:00
|
|
|
struct lockdep_map *nest_lock, unsigned long ip,
|
2013-10-17 14:45:29 +04:00
|
|
|
struct ww_acquire_ctx *ww_ctx, const bool use_ww_ctx)
|
2006-01-10 02:59:19 +03:00
|
|
|
{
|
|
|
|
struct mutex_waiter waiter;
|
2016-08-27 02:35:08 +03:00
|
|
|
struct ww_mutex *ww;
|
2013-06-24 12:30:04 +04:00
|
|
|
int ret;
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2021-03-16 18:31:16 +03:00
|
|
|
if (!use_ww_ctx)
|
|
|
|
ww_ctx = NULL;
|
|
|
|
|
2016-12-23 12:36:00 +03:00
|
|
|
might_sleep();
|
2016-12-21 21:46:32 +03:00
|
|
|
|
2021-06-30 18:35:20 +03:00
|
|
|
MUTEX_WARN_ON(lock->magic != lock);
|
2019-07-03 12:21:26 +03:00
|
|
|
|
2016-12-23 12:36:00 +03:00
|
|
|
ww = container_of(lock, struct ww_mutex, base);
|
2021-03-16 18:31:16 +03:00
|
|
|
if (ww_ctx) {
|
2016-05-26 23:08:17 +03:00
|
|
|
if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
|
|
|
|
return -EALREADY;
|
2018-06-15 11:17:38 +03: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;
|
2021-08-16 00:28:38 +03:00
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_LOCK_ALLOC
|
|
|
|
nest_lock = &ww_ctx->dep_map;
|
|
|
|
#endif
|
2016-05-26 23:08:17 +03:00
|
|
|
}
|
|
|
|
|
2009-01-14 17:36:26 +03:00
|
|
|
preempt_disable();
|
2011-05-25 04:12:03 +04:00
|
|
|
mutex_acquire_nest(&lock->dep_map, subclass, 0, nest_lock, ip);
|
2009-12-02 22:49:16 +03:00
|
|
|
|
2017-01-11 16:17:48 +03:00
|
|
|
if (__mutex_trylock(lock) ||
|
2021-03-16 18:31:16 +03:00
|
|
|
mutex_optimistic_spin(lock, ww_ctx, NULL)) {
|
2014-07-31 00:41:53 +04:00
|
|
|
/* got the lock, yay! */
|
2016-08-23 14:36:04 +03:00
|
|
|
lock_acquired(&lock->dep_map, ip);
|
2021-03-16 18:31:16 +03:00
|
|
|
if (ww_ctx)
|
2016-08-23 14:36:04 +03:00
|
|
|
ww_mutex_set_context_fastpath(ww, ww_ctx);
|
2014-07-31 00:41:53 +04:00
|
|
|
preempt_enable();
|
|
|
|
return 0;
|
2009-01-12 16:01:47 +03:00
|
|
|
}
|
2014-07-31 00:41:53 +04:00
|
|
|
|
2021-08-16 00:28:36 +03:00
|
|
|
raw_spin_lock(&lock->wait_lock);
|
2014-06-11 22:37:21 +04:00
|
|
|
/*
|
2016-08-23 14:36:04 +03:00
|
|
|
* After waiting to acquire the wait_lock, try again.
|
2014-06-11 22:37:21 +04:00
|
|
|
*/
|
2016-12-21 21:46:36 +03:00
|
|
|
if (__mutex_trylock(lock)) {
|
2021-03-16 18:31:16 +03:00
|
|
|
if (ww_ctx)
|
2018-06-15 11:07:12 +03:00
|
|
|
__ww_mutex_check_waiters(lock, ww_ctx);
|
2016-12-21 21:46:36 +03:00
|
|
|
|
2013-06-29 00:13:18 +04:00
|
|
|
goto skip_wait;
|
2016-12-21 21:46:36 +03:00
|
|
|
}
|
2013-06-29 00:13:18 +04:00
|
|
|
|
2006-07-03 11:24:33 +04:00
|
|
|
debug_mutex_lock_common(lock, &waiter);
|
2021-08-16 00:28:39 +03:00
|
|
|
waiter.task = current;
|
2021-08-19 22:30:30 +03:00
|
|
|
if (use_ww_ctx)
|
2021-08-16 00:28:39 +03:00
|
|
|
waiter.ww_ctx = ww_ctx;
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2016-12-21 21:46:34 +03:00
|
|
|
lock_contended(&lock->dep_map, ip);
|
|
|
|
|
|
|
|
if (!use_ww_ctx) {
|
|
|
|
/* add waiting tasks to the end of the waitqueue (FIFO): */
|
2018-06-15 11:17:38 +03:00
|
|
|
__mutex_add_waiter(lock, &waiter, &lock->wait_list);
|
2016-12-21 21:46:34 +03:00
|
|
|
} else {
|
2018-06-15 11:07:12 +03:00
|
|
|
/*
|
|
|
|
* Add in stamp order, waking up waiters that must kill
|
|
|
|
* themselves.
|
|
|
|
*/
|
2016-12-21 21:46:34 +03:00
|
|
|
ret = __ww_mutex_add_waiter(&waiter, lock, ww_ctx);
|
|
|
|
if (ret)
|
2018-06-15 11:07:12 +03:00
|
|
|
goto err_early_kill;
|
2016-12-21 21:46:34 +03: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 00:43:14 +03:00
|
|
|
set_current_state(state);
|
2006-01-10 02:59:19 +03:00
|
|
|
for (;;) {
|
2021-06-30 18:35:18 +03:00
|
|
|
bool first;
|
|
|
|
|
2016-09-02 14:42:12 +03: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 16:17:48 +03:00
|
|
|
if (__mutex_trylock(lock))
|
2016-09-02 14:42:12 +03:00
|
|
|
goto acquired;
|
2006-01-10 02:59:19 +03:00
|
|
|
|
|
|
|
/*
|
2018-06-15 11:07:12 +03:00
|
|
|
* Check for signals and kill conditions while holding
|
2016-09-02 14:42:12 +03:00
|
|
|
* wait_lock. This ensures the lock cancellation is ordered
|
|
|
|
* against mutex_unlock() and wake-ups do not go missing.
|
2006-01-10 02:59:19 +03:00
|
|
|
*/
|
2019-01-04 02:28:44 +03:00
|
|
|
if (signal_pending_state(state, current)) {
|
2013-06-24 12:30:04 +04:00
|
|
|
ret = -EINTR;
|
|
|
|
goto err;
|
|
|
|
}
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2021-03-16 18:31:16 +03:00
|
|
|
if (ww_ctx) {
|
2018-06-15 11:07:12 +03:00
|
|
|
ret = __ww_mutex_check_kill(lock, &waiter, ww_ctx);
|
2013-06-24 12:30:04 +04:00
|
|
|
if (ret)
|
|
|
|
goto err;
|
2006-01-10 02:59:19 +03:00
|
|
|
}
|
2013-06-24 12:30:04 +04:00
|
|
|
|
2021-08-16 00:28:36 +03:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2011-03-21 14:33:18 +03:00
|
|
|
schedule_preempt_disabled();
|
2016-08-23 15:40:16 +03:00
|
|
|
|
2021-06-30 18:35:18 +03:00
|
|
|
first = __mutex_waiter_is_first(lock, &waiter);
|
2016-09-02 14:42:12 +03: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 00:43:14 +03:00
|
|
|
set_current_state(state);
|
2016-09-02 14:42:12 +03: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.
|
|
|
|
*/
|
2021-06-30 18:35:19 +03:00
|
|
|
if (__mutex_trylock_or_handoff(lock, first) ||
|
2021-03-16 18:31:16 +03:00
|
|
|
(first && mutex_optimistic_spin(lock, ww_ctx, &waiter)))
|
2016-09-02 14:42:12 +03:00
|
|
|
break;
|
|
|
|
|
2021-08-16 00:28:36 +03:00
|
|
|
raw_spin_lock(&lock->wait_lock);
|
2006-01-10 02:59:19 +03:00
|
|
|
}
|
2021-08-16 00:28:36 +03:00
|
|
|
raw_spin_lock(&lock->wait_lock);
|
2016-09-02 14:42:12 +03: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 00:43:14 +03:00
|
|
|
__set_current_state(TASK_RUNNING);
|
2015-01-20 04:39:21 +03:00
|
|
|
|
2021-03-16 18:31:16 +03:00
|
|
|
if (ww_ctx) {
|
2018-06-15 11:17:38 +03: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);
|
|
|
|
}
|
|
|
|
|
2021-05-17 06:40:05 +03:00
|
|
|
__mutex_remove_waiter(lock, &waiter);
|
2016-08-23 14:36:04 +03:00
|
|
|
|
2013-06-29 00:13:18 +04:00
|
|
|
debug_mutex_free_waiter(&waiter);
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2013-06-29 00:13:18 +04:00
|
|
|
skip_wait:
|
|
|
|
/* got the lock - cleanup and rejoice! */
|
2008-10-17 01:17:09 +04:00
|
|
|
lock_acquired(&lock->dep_map, ip);
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2021-03-16 18:31:16 +03:00
|
|
|
if (ww_ctx)
|
2018-06-15 11:07:12 +03:00
|
|
|
ww_mutex_lock_acquired(ww, ww_ctx);
|
2013-06-24 12:30:04 +04:00
|
|
|
|
2021-08-16 00:28:36 +03:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2009-01-14 17:36:26 +03:00
|
|
|
preempt_enable();
|
2006-01-10 02:59:19 +03:00
|
|
|
return 0;
|
2013-06-24 12:30:04 +04: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 00:43:14 +03:00
|
|
|
__set_current_state(TASK_RUNNING);
|
2021-05-17 06:40:05 +03:00
|
|
|
__mutex_remove_waiter(lock, &waiter);
|
2018-06-15 11:07:12 +03:00
|
|
|
err_early_kill:
|
2021-08-16 00:28:36 +03:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2013-06-24 12:30:04 +04:00
|
|
|
debug_mutex_free_waiter(&waiter);
|
2019-09-19 19:09:40 +03:00
|
|
|
mutex_release(&lock->dep_map, ip);
|
2013-06-24 12:30:04 +04:00
|
|
|
preempt_enable();
|
|
|
|
return ret;
|
2006-01-10 02:59:19 +03:00
|
|
|
}
|
|
|
|
|
2016-12-23 12:36:00 +03:00
|
|
|
static int __sched
|
2021-06-11 11:28:17 +03:00
|
|
|
__mutex_lock(struct mutex *lock, unsigned int state, unsigned int subclass,
|
2016-12-23 12:36:00 +03:00
|
|
|
struct lockdep_map *nest_lock, unsigned long ip)
|
|
|
|
{
|
|
|
|
return __mutex_lock_common(lock, state, subclass, nest_lock, ip, NULL, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __sched
|
2021-06-11 11:28:17 +03:00
|
|
|
__ww_mutex_lock(struct mutex *lock, unsigned int state, unsigned int subclass,
|
2021-08-16 00:28:38 +03:00
|
|
|
unsigned long ip, struct ww_acquire_ctx *ww_ctx)
|
2016-12-23 12:36:00 +03:00
|
|
|
{
|
2021-08-16 00:28:38 +03:00
|
|
|
return __mutex_lock_common(lock, state, subclass, NULL, ip, ww_ctx, true);
|
2016-12-23 12:36:00 +03:00
|
|
|
}
|
|
|
|
|
2006-07-03 11:24:55 +04:00
|
|
|
#ifdef CONFIG_DEBUG_LOCK_ALLOC
|
|
|
|
void __sched
|
|
|
|
mutex_lock_nested(struct mutex *lock, unsigned int subclass)
|
|
|
|
{
|
2016-12-23 12:36:00 +03:00
|
|
|
__mutex_lock(lock, TASK_UNINTERRUPTIBLE, subclass, NULL, _RET_IP_);
|
2006-07-03 11:24:55 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL_GPL(mutex_lock_nested);
|
2006-12-08 13:36:17 +03:00
|
|
|
|
2011-05-25 04:12:03 +04:00
|
|
|
void __sched
|
|
|
|
_mutex_lock_nest_lock(struct mutex *lock, struct lockdep_map *nest)
|
|
|
|
{
|
2016-12-23 12:36:00 +03:00
|
|
|
__mutex_lock(lock, TASK_UNINTERRUPTIBLE, 0, nest, _RET_IP_);
|
2011-05-25 04:12:03 +04:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(_mutex_lock_nest_lock);
|
|
|
|
|
2007-12-07 01:37:59 +03:00
|
|
|
int __sched
|
|
|
|
mutex_lock_killable_nested(struct mutex *lock, unsigned int subclass)
|
|
|
|
{
|
2016-12-23 12:36:00 +03:00
|
|
|
return __mutex_lock(lock, TASK_KILLABLE, subclass, NULL, _RET_IP_);
|
2007-12-07 01:37:59 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mutex_lock_killable_nested);
|
|
|
|
|
2006-12-08 13:36:17 +03:00
|
|
|
int __sched
|
|
|
|
mutex_lock_interruptible_nested(struct mutex *lock, unsigned int subclass)
|
|
|
|
{
|
2016-12-23 12:36:00 +03:00
|
|
|
return __mutex_lock(lock, TASK_INTERRUPTIBLE, subclass, NULL, _RET_IP_);
|
2006-12-08 13:36:17 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mutex_lock_interruptible_nested);
|
2013-06-24 12:30:04 +04:00
|
|
|
|
2016-10-28 19:58:11 +03: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 15:31:17 +04: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 12:30:04 +04:00
|
|
|
|
|
|
|
int __sched
|
2016-12-21 21:46:33 +03:00
|
|
|
ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
|
2013-06-24 12:30:04 +04:00
|
|
|
{
|
2013-06-20 15:31:17 +04:00
|
|
|
int ret;
|
|
|
|
|
2013-06-24 12:30:04 +04:00
|
|
|
might_sleep();
|
2016-12-23 12:36:00 +03:00
|
|
|
ret = __ww_mutex_lock(&lock->base, TASK_UNINTERRUPTIBLE,
|
2021-08-16 00:28:38 +03:00
|
|
|
0, _RET_IP_, ctx);
|
2016-12-21 21:46:32 +03:00
|
|
|
if (!ret && ctx && ctx->acquired > 1)
|
2013-06-20 15:31:17 +04:00
|
|
|
return ww_mutex_deadlock_injection(lock, ctx);
|
|
|
|
|
|
|
|
return ret;
|
2013-06-24 12:30:04 +04:00
|
|
|
}
|
2016-12-21 21:46:33 +03:00
|
|
|
EXPORT_SYMBOL_GPL(ww_mutex_lock);
|
2013-06-24 12:30:04 +04:00
|
|
|
|
|
|
|
int __sched
|
2016-12-21 21:46:33 +03:00
|
|
|
ww_mutex_lock_interruptible(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
|
2013-06-24 12:30:04 +04:00
|
|
|
{
|
2013-06-20 15:31:17 +04:00
|
|
|
int ret;
|
|
|
|
|
2013-06-24 12:30:04 +04:00
|
|
|
might_sleep();
|
2016-12-23 12:36:00 +03:00
|
|
|
ret = __ww_mutex_lock(&lock->base, TASK_INTERRUPTIBLE,
|
2021-08-16 00:28:38 +03:00
|
|
|
0, _RET_IP_, ctx);
|
2013-06-20 15:31:17 +04:00
|
|
|
|
2016-12-21 21:46:32 +03:00
|
|
|
if (!ret && ctx && ctx->acquired > 1)
|
2013-06-20 15:31:17 +04:00
|
|
|
return ww_mutex_deadlock_injection(lock, ctx);
|
|
|
|
|
|
|
|
return ret;
|
2013-06-24 12:30:04 +04:00
|
|
|
}
|
2016-12-21 21:46:33 +03:00
|
|
|
EXPORT_SYMBOL_GPL(ww_mutex_lock_interruptible);
|
2013-06-24 12:30:04 +04:00
|
|
|
|
2006-07-03 11:24:55 +04:00
|
|
|
#endif
|
|
|
|
|
2006-01-10 02:59:19 +03:00
|
|
|
/*
|
|
|
|
* Release the lock, slowpath:
|
|
|
|
*/
|
2016-08-23 14:36:04 +03:00
|
|
|
static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigned long ip)
|
2006-01-10 02:59:19 +03:00
|
|
|
{
|
2016-08-23 15:40:16 +03:00
|
|
|
struct task_struct *next = NULL;
|
2016-11-17 19:46:38 +03:00
|
|
|
DEFINE_WAKE_Q(wake_q);
|
2017-01-17 18:06:09 +03:00
|
|
|
unsigned long owner;
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2019-09-19 19:09:40 +03:00
|
|
|
mutex_release(&lock->dep_map, ip);
|
2016-08-23 14:36:04 +03:00
|
|
|
|
2006-01-10 02:59:19 +03:00
|
|
|
/*
|
2016-08-23 15:40:16 +03: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 02:59:19 +03:00
|
|
|
*/
|
2016-08-23 15:40:16 +03:00
|
|
|
owner = atomic_long_read(&lock->owner);
|
|
|
|
for (;;) {
|
2021-06-30 18:35:20 +03:00
|
|
|
MUTEX_WARN_ON(__owner_task(owner) != current);
|
|
|
|
MUTEX_WARN_ON(owner & MUTEX_FLAG_PICKUP);
|
2016-08-23 15:40:16 +03:00
|
|
|
|
|
|
|
if (owner & MUTEX_FLAG_HANDOFF)
|
|
|
|
break;
|
|
|
|
|
2021-06-30 18:35:17 +03:00
|
|
|
if (atomic_long_try_cmpxchg_release(&lock->owner, &owner, __owner_flags(owner))) {
|
2016-08-23 15:40:16 +03:00
|
|
|
if (owner & MUTEX_FLAG_WAITERS)
|
|
|
|
break;
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2021-08-16 00:28:36 +03:00
|
|
|
raw_spin_lock(&lock->wait_lock);
|
2014-01-28 23:13:14 +04:00
|
|
|
debug_mutex_unlock(lock);
|
2006-01-10 02:59:19 +03:00
|
|
|
if (!list_empty(&lock->wait_list)) {
|
|
|
|
/* get the first entry from the wait-list: */
|
|
|
|
struct mutex_waiter *waiter =
|
2016-08-23 15:40:16 +03:00
|
|
|
list_first_entry(&lock->wait_list,
|
|
|
|
struct mutex_waiter, list);
|
|
|
|
|
|
|
|
next = waiter->task;
|
2006-01-10 02:59:19 +03:00
|
|
|
|
|
|
|
debug_mutex_wake_waiter(lock, waiter);
|
2016-08-23 15:40:16 +03:00
|
|
|
wake_q_add(&wake_q, next);
|
2006-01-10 02:59:19 +03:00
|
|
|
}
|
|
|
|
|
2016-08-23 15:40:16 +03:00
|
|
|
if (owner & MUTEX_FLAG_HANDOFF)
|
|
|
|
__mutex_handoff(lock, next);
|
|
|
|
|
2021-08-16 00:28:36 +03:00
|
|
|
raw_spin_unlock(&lock->wait_lock);
|
2016-08-23 15:40:16 +03:00
|
|
|
|
2016-01-25 05:23:43 +03:00
|
|
|
wake_up_q(&wake_q);
|
2006-01-10 02:59:19 +03:00
|
|
|
}
|
|
|
|
|
2007-10-12 00:11:12 +04:00
|
|
|
#ifndef CONFIG_DEBUG_LOCK_ALLOC
|
2006-01-10 02:59:19 +03:00
|
|
|
/*
|
|
|
|
* Here come the less common (and hence less performance-critical) APIs:
|
|
|
|
* mutex_lock_interruptible() and mutex_trylock().
|
|
|
|
*/
|
2008-02-08 15:19:53 +03:00
|
|
|
static noinline int __sched
|
2013-06-20 15:31:05 +04:00
|
|
|
__mutex_lock_killable_slowpath(struct mutex *lock);
|
2007-12-07 01:37:59 +03:00
|
|
|
|
2008-02-08 15:19:53 +03:00
|
|
|
static noinline int __sched
|
2013-06-20 15:31:05 +04:00
|
|
|
__mutex_lock_interruptible_slowpath(struct mutex *lock);
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2010-09-03 02:48:16 +04:00
|
|
|
/**
|
2018-03-15 14:58:12 +03:00
|
|
|
* mutex_lock_interruptible() - Acquire the mutex, interruptible by signals.
|
|
|
|
* @lock: The mutex to be acquired.
|
2006-01-10 02:59:19 +03:00
|
|
|
*
|
2018-03-15 14:58:12 +03: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 02:59:19 +03:00
|
|
|
*
|
2018-03-15 14:58:12 +03:00
|
|
|
* Context: Process context.
|
|
|
|
* Return: 0 if the lock was successfully acquired or %-EINTR if a
|
|
|
|
* signal arrived.
|
2006-01-10 02:59:19 +03:00
|
|
|
*/
|
2008-02-08 15:19:53 +03:00
|
|
|
int __sched mutex_lock_interruptible(struct mutex *lock)
|
2006-01-10 02:59:19 +03:00
|
|
|
{
|
2006-01-11 00:10:36 +03:00
|
|
|
might_sleep();
|
2016-08-23 14:36:04 +03:00
|
|
|
|
|
|
|
if (__mutex_trylock_fast(lock))
|
2013-06-20 15:31:05 +04:00
|
|
|
return 0;
|
2016-08-23 14:36:04 +03:00
|
|
|
|
|
|
|
return __mutex_lock_interruptible_slowpath(lock);
|
2006-01-10 02:59:19 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL(mutex_lock_interruptible);
|
|
|
|
|
2018-03-15 14:58:12 +03: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 15:19:53 +03:00
|
|
|
int __sched mutex_lock_killable(struct mutex *lock)
|
2007-12-07 01:37:59 +03:00
|
|
|
{
|
|
|
|
might_sleep();
|
2016-08-23 14:36:04 +03:00
|
|
|
|
|
|
|
if (__mutex_trylock_fast(lock))
|
2013-06-20 15:31:05 +04:00
|
|
|
return 0;
|
2016-08-23 14:36:04 +03:00
|
|
|
|
|
|
|
return __mutex_lock_killable_slowpath(lock);
|
2007-12-07 01:37:59 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mutex_lock_killable);
|
|
|
|
|
2018-03-15 14:58:12 +03: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-28 19:58:11 +03: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 14:36:04 +03:00
|
|
|
static noinline void __sched
|
|
|
|
__mutex_lock_slowpath(struct mutex *lock)
|
2007-10-12 00:11:12 +04:00
|
|
|
{
|
2016-12-23 12:36:00 +03:00
|
|
|
__mutex_lock(lock, TASK_UNINTERRUPTIBLE, 0, NULL, _RET_IP_);
|
2007-10-12 00:11:12 +04:00
|
|
|
}
|
|
|
|
|
2008-02-08 15:19:53 +03:00
|
|
|
static noinline int __sched
|
2013-06-20 15:31:05 +04:00
|
|
|
__mutex_lock_killable_slowpath(struct mutex *lock)
|
2007-12-07 01:37:59 +03:00
|
|
|
{
|
2016-12-23 12:36:00 +03:00
|
|
|
return __mutex_lock(lock, TASK_KILLABLE, 0, NULL, _RET_IP_);
|
2007-12-07 01:37:59 +03:00
|
|
|
}
|
|
|
|
|
2008-02-08 15:19:53 +03:00
|
|
|
static noinline int __sched
|
2013-06-20 15:31:05 +04:00
|
|
|
__mutex_lock_interruptible_slowpath(struct mutex *lock)
|
2006-01-10 02:59:19 +03:00
|
|
|
{
|
2016-12-23 12:36:00 +03:00
|
|
|
return __mutex_lock(lock, TASK_INTERRUPTIBLE, 0, NULL, _RET_IP_);
|
2013-06-24 12:30:04 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static noinline int __sched
|
|
|
|
__ww_mutex_lock_slowpath(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
|
|
|
|
{
|
2021-08-16 00:28:38 +03:00
|
|
|
return __ww_mutex_lock(&lock->base, TASK_UNINTERRUPTIBLE, 0,
|
2016-12-23 12:36:00 +03:00
|
|
|
_RET_IP_, ctx);
|
2006-01-10 02:59:19 +03:00
|
|
|
}
|
2013-06-24 12:30:04 +04:00
|
|
|
|
|
|
|
static noinline int __sched
|
|
|
|
__ww_mutex_lock_interruptible_slowpath(struct ww_mutex *lock,
|
|
|
|
struct ww_acquire_ctx *ctx)
|
|
|
|
{
|
2021-08-16 00:28:38 +03:00
|
|
|
return __ww_mutex_lock(&lock->base, TASK_INTERRUPTIBLE, 0,
|
2016-12-23 12:36:00 +03:00
|
|
|
_RET_IP_, ctx);
|
2013-06-24 12:30:04 +04:00
|
|
|
}
|
|
|
|
|
2007-10-12 00:11:12 +04:00
|
|
|
#endif
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2010-09-03 02:48:16 +04:00
|
|
|
/**
|
|
|
|
* mutex_trylock - try to acquire the mutex, without waiting
|
2006-01-10 02:59:19 +03: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 02:48:16 +04:00
|
|
|
* it is negated from the down_trylock() return values! Be careful
|
2006-01-10 02:59:19 +03: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 15:19:53 +03:00
|
|
|
int __sched mutex_trylock(struct mutex *lock)
|
2006-01-10 02:59:19 +03:00
|
|
|
{
|
2019-07-03 12:21:26 +03:00
|
|
|
bool locked;
|
|
|
|
|
2021-06-30 18:35:20 +03:00
|
|
|
MUTEX_WARN_ON(lock->magic != lock);
|
2009-01-12 16:01:47 +03:00
|
|
|
|
2019-07-03 12:21:26 +03:00
|
|
|
locked = __mutex_trylock(lock);
|
2016-08-23 14:36:04 +03:00
|
|
|
if (locked)
|
|
|
|
mutex_acquire(&lock->dep_map, 0, 1, _RET_IP_);
|
2009-01-12 16:01:47 +03:00
|
|
|
|
2016-08-23 14:36:04 +03:00
|
|
|
return locked;
|
2006-01-10 02:59:19 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(mutex_trylock);
|
2009-04-30 02:59:58 +04:00
|
|
|
|
2013-06-24 12:30:04 +04:00
|
|
|
#ifndef CONFIG_DEBUG_LOCK_ALLOC
|
|
|
|
int __sched
|
2016-12-21 21:46:33 +03:00
|
|
|
ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
|
2013-06-24 12:30:04 +04:00
|
|
|
{
|
|
|
|
might_sleep();
|
|
|
|
|
2016-08-23 14:36:04 +03:00
|
|
|
if (__mutex_trylock_fast(&lock->base)) {
|
2016-12-21 21:46:32 +03:00
|
|
|
if (ctx)
|
|
|
|
ww_mutex_set_context_fastpath(lock, ctx);
|
2016-08-23 14:36:04 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return __ww_mutex_lock_slowpath(lock, ctx);
|
2013-06-24 12:30:04 +04:00
|
|
|
}
|
2016-12-21 21:46:33 +03:00
|
|
|
EXPORT_SYMBOL(ww_mutex_lock);
|
2013-06-24 12:30:04 +04:00
|
|
|
|
|
|
|
int __sched
|
2016-12-21 21:46:33 +03:00
|
|
|
ww_mutex_lock_interruptible(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
|
2013-06-24 12:30:04 +04:00
|
|
|
{
|
|
|
|
might_sleep();
|
|
|
|
|
2016-08-23 14:36:04 +03:00
|
|
|
if (__mutex_trylock_fast(&lock->base)) {
|
2016-12-21 21:46:32 +03:00
|
|
|
if (ctx)
|
|
|
|
ww_mutex_set_context_fastpath(lock, ctx);
|
2016-08-23 14:36:04 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return __ww_mutex_lock_interruptible_slowpath(lock, ctx);
|
2013-06-24 12:30:04 +04:00
|
|
|
}
|
2016-12-21 21:46:33 +03:00
|
|
|
EXPORT_SYMBOL(ww_mutex_lock_interruptible);
|
2013-06-24 12:30:04 +04:00
|
|
|
|
2021-08-16 00:29:01 +03:00
|
|
|
#endif /* !CONFIG_DEBUG_LOCK_ALLOC */
|
|
|
|
#endif /* !CONFIG_PREEMPT_RT */
|
2013-06-24 12:30:04 +04:00
|
|
|
|
2009-04-30 02:59:58 +04: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);
|