From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756611AbcILPVE (ORCPT ); Mon, 12 Sep 2016 11:21:04 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:44143 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755052AbcILPVD (ORCPT ); Mon, 12 Sep 2016 11:21:03 -0400 Date: Mon, 12 Sep 2016 17:20:52 +0200 From: Peter Zijlstra To: Waiman Long Cc: Linus Torvalds , Jason Low , Ding Tianhong , Thomas Gleixner , Will Deacon , Ingo Molnar , Imre Deak , Linux Kernel Mailing List , Davidlohr Bueso , Tim Chen , Terry Rudd , "Paul E. McKenney" , Jason Low Subject: Re: [RFC][PATCH -v3 10/10] locking/mutex: Implement alternative HANDOFF Message-ID: <20160912152052.GT10153@twins.programming.kicks-ass.net> References: <20160905123636.450529224@infradead.org> <20160905124027.796192899@infradead.org> <57D33864.4060201@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57D33864.4060201@hpe.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 09, 2016 at 06:32:04PM -0400, Waiman Long wrote: > I have another way of catching the uncleared handoff flag. See the following > code to see if you think that will work. > > diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c > index 9492494..362ff83 100644 > --- a/kernel/locking/mutex.c > +++ b/kernel/locking/mutex.c > @@ -85,7 +85,13 @@ static inline bool __mutex_trylock(struct mutex *lock, > const > > owner = atomic_long_read(&lock->owner); > for (;;) { /* must loop, can race against a flag */ > - unsigned long old; > + unsigned long old, flags = __owner_flags(owner); > + > + /* > + * We don't need to keep the HANDOFF flag for the waiter. > + */ > + if (handoff) > + flags &= ~MUTEX_FLAG_HANDOFF; > > if (__owner_task(owner)) { > if (handoff && unlikely(__owner_task(owner) == current)) I placed this condition below the __owner_task() branch. > @@ -688,7 +694,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned > * state back to RUNNING and fall through the next schedule(), > * or we must see its unlock and acquire. > */ > - if (__mutex_trylock(lock, true)) > + if (__mutex_trylock(lock, first)) > break; > > spin_lock_mutex(&lock->wait_lock, flags); Hmm, yes. I think that works. We (the first waiter) set the flag, we clear it on try-lock, or unlock clears it when it hands the thing off. Much simpler. Thanks!