linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
Subject: Re: [PATCH 4/5] locking/rwsem: Avoid deceiving lock spinners
Date: Tue, 03 Feb 2015 09:16:52 -0800	[thread overview]
Message-ID: <1422983812.9530.43.camel@schen9-desk2.jf.intel.com> (raw)
In-Reply-To: <1422671289.28351.1.camel@stgolabs.net>


> > >  
> > > +	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



  reply	other threads:[~2015-02-03 17:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-30  9:14 [PATCH -tip v2 0/5] rwsem: Fine tuning Davidlohr Bueso
2015-01-30  9:14 ` [PATCH 1/5] locking/rwsem: Use task->state helpers Davidlohr Bueso
2015-01-30  9:14 ` [PATCH 2/5] locking/rwsem: Document barrier need when waking tasks Davidlohr Bueso
2015-02-18 17:11   ` [tip:locking/core] " tip-bot for Davidlohr Bueso
2015-01-30  9:14 ` [PATCH 3/5] locking/rwsem: Set lock ownership ASAP Davidlohr Bueso
2015-02-18 17:11   ` [tip:locking/core] " tip-bot for Davidlohr Bueso
2015-01-30  9:14 ` [PATCH 4/5] locking/rwsem: Avoid deceiving lock spinners Davidlohr Bueso
2015-01-31  1:51   ` Tim Chen
2015-01-31  2:28     ` Davidlohr Bueso
2015-02-03 17:16       ` Tim Chen [this message]
2015-02-03 17:54         ` Jason Low
2015-02-03 19:43           ` Tim Chen
2015-02-03 21:04             ` Jason Low
2015-02-03 21:48               ` Tim Chen
2015-02-04 12:06             ` Peter Zijlstra
2015-02-04 17:39               ` Tim Chen
2015-01-31  9:29   ` Peter Zijlstra
2015-01-31 21:14     ` Davidlohr Bueso
2015-01-31 21:17       ` Davidlohr Bueso
2015-02-18 17:12   ` [tip:locking/core] " tip-bot for Davidlohr Bueso
2015-01-30  9:14 ` [PATCH 5/5] locking/rwsem: Check for active lock before bailing on spinning Davidlohr Bueso
2015-02-18 17:12   ` [tip:locking/core] " tip-bot for Davidlohr Bueso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1422983812.9530.43.camel@schen9-desk2.jf.intel.com \
    --to=tim.c.chen@linux.intel.com \
    --cc=dave@stgolabs.net \
    --cc=jason.low2@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=walken@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).