Messages in this thread | | | Date | Mon, 25 Jan 2016 18:02:29 -0500 | From | Waiman Long <> | Subject | Re: [PATCH] locking/mutex: Allow next waiter lockless wakeup |
| |
On 01/24/2016 09:23 PM, Davidlohr Bueso wrote: > 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 <dbueso@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); > } > > /*
This patch looks good to me.
Reviewed-by: Waiman Long <Waiman.Long@hpe.com>
| |