Make use of wake_q and enable the wakeup to occur after
releasing the wait_lock. This is similar to what we do
with rtmutex top waiter, slightly shortening the critical
region and allow other waiters to acquire the wait_lock
sooner. In low contention cases it can also help the
recently woken waiter to find the wait_lock available
(fastpath) when it continues execution.

Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
 kernel/locking/mutex.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 0551c21..e364b42 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -716,6 +716,7 @@ static inline void
 __mutex_unlock_common_slowpath(struct mutex *lock, int nested)
 {
        unsigned long flags;
+       WAKE_Q(wake_q);
/*
         * As a performance measurement, release the lock before doing other
@@ -743,11 +744,11 @@ __mutex_unlock_common_slowpath(struct mutex *lock, int 
nested)
                                           struct mutex_waiter, list);
debug_mutex_wake_waiter(lock, waiter);
-
-               wake_up_process(waiter->task);
+               wake_q_add(&wake_q, waiter->task);
        }
spin_unlock_mutex(&lock->wait_lock, flags);
+       wake_up_q(&wake_q);
 }
/*
--
2.1.4

Reply via email to