Re: [PATCH -v4 8/8] locking/mutex: Enable optimistic spinning of woken waiter

From	Peter Zijlstra <peterz@infradead.org>
Newsgroups	linux.kernel
Subject	Re: [PATCH -v4 8/8] locking/mutex: Enable optimistic spinning of woken waiter
Date	2016-10-17 11:40 +0200
Message-ID	<stcyK-1Fs-17@gated-at.bofh.it> (permalink)
References	<spEWB-2dt-5@gated-at.bofh.it> <spFfX-2lv-31@gated-at.bofh.it> <srQ7f-5ge-13@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Thu, Oct 13, 2016 at 04:28:01PM +0100, Will Deacon wrote:
> On Fri, Oct 07, 2016 at 04:52:51PM +0200, Peter Zijlstra wrote:

> > @@ -457,15 +472,20 @@ static bool mutex_optimistic_spin(struct
> >  		 * release the lock or go to sleep.
> >  		 */
> >  		owner = __mutex_owner(lock);
> > -		if (owner && !mutex_spin_on_owner(lock, owner))
> > -			break;
> > +		if (owner) {
> > +			if (waiter && owner == task) {
> > +				smp_mb(); /* ACQUIRE */
> 
> Hmm, is this barrier actually needed? This only happens on the handoff path,
> and we take the wait_lock immediately after this succeeds anyway. That
> control dependency, coupled with the acquire semantics of the spin_lock,
> should be sufficient, no?

Yes, I think you're right. But like said in that earlier email, I'd like
to keep this for now.

Once this code has settled we can reconsider this.

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [PATCH -v4 8/8] locking/mutex: Enable optimistic spinning of  woken waiter Will Deacon <will.deacon@arm.com> - 2016-10-13 17:30 +0200
  Re: [PATCH -v4 8/8] locking/mutex: Enable optimistic spinning of  woken waiter Peter Zijlstra <peterz@infradead.org> - 2016-10-17 11:40 +0200

csiph-web