From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753391AbcAUVXL (ORCPT <rfc822;w@1wt.eu>);
	Thu, 21 Jan 2016 16:23:11 -0500
Received: from mga01.intel.com ([192.55.52.88]:60270 "EHLO mga01.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751402AbcAUVXK (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 21 Jan 2016 16:23:10 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.22,327,1449561600"; 
   d="scan'208";a="895655319"
Message-ID: <1453411389.30844.38.camel@schen9-desk2.jf.intel.com>
Subject: Re: [PATCH RFC] locking/mutexes: don't spin on owner when wait list
 is not NULL.
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Ding Tianhong <dingtianhong@huawei.com>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Davidlohr Bueso <dave@stgolabs.net>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        "Paul E. McKenney" <paulmck@us.ibm.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Will Deacon <Will.Deacon@arm.com>, Jason Low <jason.low2@hp.com>,
        Waiman Long <Waiman.Long@hp.com>
Date: Thu, 21 Jan 2016 13:23:09 -0800
In-Reply-To: <56A0A4ED.3070308@huawei.com>
References: <56A0A4ED.3070308@huawei.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

Tim