linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Jason Low <jason.low2@hp.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Ingo Molnar <mingo@kernel.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Michel Lespinasse <walken@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] locking/rwsem: Avoid deceiving lock spinners
Date: Wed, 04 Feb 2015 09:39:04 -0800	[thread overview]
Message-ID: <1423071544.9530.107.camel@schen9-desk2.jf.intel.com> (raw)
In-Reply-To: <20150204120621.GH23123@twins.programming.kicks-ass.net>

On Wed, 2015-02-04 at 13:06 +0100, Peter Zijlstra wrote:
> On Tue, Feb 03, 2015 at 11:43:36AM -0800, Tim Chen wrote:
> > That's true.  We cannot have the lock grabbed by a new write 
> > contender as any new writer contender of the lock will be 
> > queued by the OSQ logic. Only the
> > thread doing the optimistic spin is attempting write lock.  
> > In other word, switching of write owner of the rwsem to a new
> > owner cannot happen.  Either write owner stay as the original one, or
> > we don't have a write owner.  So using test of write owner
> > switching as an indicator of congestion is incorrect.
> > 
> > If my reasoning above is sound, then the check 
> > 
> > +       if (READ_ONCE(sem->owner))
> > +               return true; /* new owner, continue spinning */
> > +
> > 
> > is unnecessary and can be removed, as we cannot have a 
> > new write owner of the rwsem, other than the thread
> > doing optimistic spinning.
> 
> I have read the rest of the thread; but the one thing that I didn't see
> is trylocks, trylocks can always come in an steal things regardless of
> the OSQ stuff.

Jason also pointed that out.  So the owner change check is needed
after all.  Now because of the OSQ logic, even if owner has changed,
the likelihood that the spinner at the head of OSQ will acquire the
lock is high.  So it should continue to spin.

That's because any new threads coming in will try lock only
once, and go to the OSQ. It is unlikely that they will trylock at
the precise moment when the owner release the lock as they do not
continue to spin on the lock.  The contention from new threads
are low.

So letting the thread at head of OSQ to continue to spin is probably
the right thing to do.

Tim


  reply	other threads:[~2015-02-04 17:39 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
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 [this message]
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=1423071544.9530.107.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).