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 S966313AbbBCRQ5 (ORCPT <rfc822;w@1wt.eu>);
	Tue, 3 Feb 2015 12:16:57 -0500
Received: from mga03.intel.com ([134.134.136.65]:59137 "EHLO mga03.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S965829AbbBCRQy (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 3 Feb 2015 12:16:54 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.09,513,1418112000"; 
   d="scan'208";a="646759917"
Message-ID: <1422983812.9530.43.camel@schen9-desk2.jf.intel.com>
Subject: Re: [PATCH 4/5] locking/rwsem: Avoid deceiving lock spinners
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Jason Low <jason.low2@hp.com>, Michel Lespinasse <walken@google.com>,
        linux-kernel@vger.kernel.org
Date: Tue, 03 Feb 2015 09:16:52 -0800
In-Reply-To: <1422671289.28351.1.camel@stgolabs.net>
References: <1422609267-15102-1-git-send-email-dave@stgolabs.net>
	 <1422609267-15102-5-git-send-email-dave@stgolabs.net>
	 <1422669098.9530.33.camel@schen9-desk2.jf.intel.com>
	 <1422671289.28351.1.camel@stgolabs.net>
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


> > >  
> > > +	if (READ_ONCE(sem->owner))
> > > +		return true; /* new owner, continue spinning */
> > > +
> > 
> > Do you have some comparison data of whether it is more advantageous
> > to continue spinning when owner changes?  After the above change, 
> > rwsem will behave more like a spin lock for write lock and 
> > will keep spinning when the lock changes ownership.
> 
> But recall we still abort when need_resched, so the spinning isn't
> infinite. Never has been.
> 
> >  Now during heavy
> > lock contention, if we don't continue spinning and sleep, we may use the
> > clock cycles for actually running other threads. 
> 
> Under heavy contention, time spinning will force us to ultimately block
> anyway.

The question is under heavy contention, if we are going to block anyway,
won't it be more advantageous not to continue spinning so we can use
the cycles for useful task?  The original code assumes that if the lock
has switched owner, then we are under heavy contention and we can stop
spinning and block.  I think it'll be useful to have some
data comparing the two behaviors.

Thanks.

Tim