From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756027AbcJLT7g (ORCPT ); Wed, 12 Oct 2016 15:59:36 -0400 Received: from g2t4625.austin.hp.com ([15.73.212.76]:47811 "EHLO g2t4625.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755880AbcJLT73 (ORCPT ); Wed, 12 Oct 2016 15:59:29 -0400 Message-ID: <1476301978.12723.41.camel@j-VirtualBox> Subject: Re: [PATCH -v4 2/8] locking/mutex: Rework mutex::owner From: Jason Low To: Davidlohr Bueso Cc: jason.low2@hpe.com, Peter Zijlstra , Linus Torvalds , Waiman Long , Ding Tianhong , Thomas Gleixner , Will Deacon , Ingo Molnar , Imre Deak , Linux Kernel Mailing List , Tim Chen , Terry Rudd , "Paul E. McKenney" , Chris Wilson , Daniel Vetter Date: Wed, 12 Oct 2016 12:52:58 -0700 In-Reply-To: <20161012175932.GA4908@linux-80c1.suse> References: <20161007145243.361481786@infradead.org> <20161007150210.995135898@infradead.org> <20161012175932.GA4908@linux-80c1.suse> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2016-10-12 at 10:59 -0700, Davidlohr Bueso wrote: > On Fri, 07 Oct 2016, Peter Zijlstra wrote: > >+/* > >+ * 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; > >+ > >+ if (!atomic_long_cmpxchg_acquire(&lock->owner, 0UL, curr)) > >+ return true; > > Do we want to do a ccas check for !lock->owner? Although I can see a possible > case of 'optimizing for the contended' reasons for nay. Since this is the fast path version that gets used in mutex_lock(), ect..., I think it would make sense to keep it like it is so that we optimize it for the "common" case. This trylock function is more likely to succeed as it is used for the initial attempt to get the mutex, so I think we could avoid the ccas in the trylock_fast(). Jason