From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752208AbcAVCln (ORCPT ); Thu, 21 Jan 2016 21:41:43 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]:35781 "EHLO e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752092AbcAVClI (ORCPT ); Thu, 21 Jan 2016 21:41:08 -0500 X-IBM-Helo: d03dlp03.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Thu, 21 Jan 2016 18:41:08 -0800 From: "Paul E. McKenney" To: Tim Chen Cc: Ding Tianhong , Peter Zijlstra , Ingo Molnar , "linux-kernel@vger.kernel.org" , Davidlohr Bueso , Linus Torvalds , Thomas Gleixner , Will Deacon , Jason Low , Waiman Long Subject: Re: [PATCH RFC] locking/mutexes: don't spin on owner when wait list is not NULL. Message-ID: <20160122024108.GH3818@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <56A0A4ED.3070308@huawei.com> <1453411389.30844.38.camel@schen9-desk2.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1453411389.30844.38.camel@schen9-desk2.jf.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16012202-0009-0000-0000-000011A561C2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 21, 2016 at 01:23:09PM -0800, Tim Chen wrote: > On Thu, 2016-01-21 at 17:29 +0800, Ding Tianhong wrote: > > > > > diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c > > index 0551c21..596b341 100644 > > --- a/kernel/locking/mutex.c > > +++ b/kernel/locking/mutex.c > > @@ -256,7 +256,7 @@ static inline int mutex_can_spin_on_owner(struct mutex *lock) > > struct task_struct *owner; > > int retval = 1; > > > > - if (need_resched()) > > + if (need_resched() || atomic_read(&lock->count) == -1) > > return 0; > > > > One concern I have is this change will eliminate any optimistic spinning > as long as there is a waiter. Is there a middle ground that we > can allow only one spinner if there are waiters? > > In other words, we allow spinning when > atomic_read(&lock->count) == -1 but there is no one on the > osq lock that queue up the spinners (i.e. no other process doing > optimistic spinning). > > This could allow a bit of spinning without starving out the waiters. I did some testing, which exposed it to the 0day test robot, which did note some performance differences. I was hoping that it would clear up some instability from other patches, but no such luck. ;-) Thanx, Paul