From: peterz@infradead.org (Peter Zijlstra)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/3] arm64: spinlock: use lock->owner to optimise spin_unlock_wait
Date: Fri, 10 Jun 2016 15:13:36 +0200 [thread overview]
Message-ID: <20160610131336.GD30154@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20160610124623.GG15668@arm.com>
On Fri, Jun 10, 2016 at 01:46:23PM +0100, Will Deacon wrote:
> On Fri, Jun 10, 2016 at 02:25:20PM +0200, Peter Zijlstra wrote:
> > On Wed, Jun 08, 2016 at 05:25:39PM +0100, Will Deacon wrote:
> > > Rather than wait until we observe the lock being free, we can also
> > > return from spin_unlock_wait if we observe that the lock is now held
> > > by somebody else, which implies that it was unlocked but we just missed
> > > seeing it in that state.
> > >
> > > Furthermore, in such a scenario there is no longer a need to write back
> > > the value that we loaded, since we know that there has been a lock
> > > hand-off, which is sufficient to publish any stores prior to the
> > > unlock_wait.
> >
> > You might want a few words on _why_ here. It took me a little while to
> > figure that out.
>
> How about "... because the ARM architecture ensures that a Store-Release
> is multi-copy-atomic when observed by a Load-Acquire instruction"?
Yep, that works.
> > Also; human readable arguments to support the thing below go a long way
> > into validating the test is indeed correct. Because as you've shown,
> > even the validators cannot be trusted ;-)
>
> Well, I didn't actually provide the output of a model here. I'm just
> capturing the rationale in a non-ambiguous form.
the litmus tests captures the problem statement, not the rationale for
the outcome.
> > > The litmus test is something like:
> > >
> > > AArch64
> > > {
> > > 0:X1=x; 0:X3=y;
> > > 1:X1=y;
> > > 2:X1=y; 2:X3=x;
> > > }
> > > P0 | P1 | P2 ;
> > > MOV W0,#1 | MOV W0,#1 | LDAR W0,[X1] ;
> > > STR W0,[X1] | STLR W0,[X1] | LDR W2,[X3] ;
> > > DMB SY | | ;
> > > LDR W2,[X3] | | ;
> > > exists
> > > (0:X2=0 /\ 2:X0=1 /\ 2:X2=0)
> > >
> > > where P0 is doing spin_unlock_wait, P1 is doing spin_unlock and P2 is
> > > doing spin_lock.
> >
> > I still have a hard time deciphering these things..
>
> I'll nail you down at LPC and share the kool-aid :)
hehe; so I can more or less parse them, its just that it doesn't come
natural to me, and I keep forgetting ARM asm which doesn't help.
next prev parent reply other threads:[~2016-06-10 13:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-08 16:25 [PATCH v2 1/3] arm64: spinlock: order spin_{is_locked, unlock_wait} against local locks Will Deacon
2016-06-08 16:25 ` [PATCH v2 2/3] arm64: spinlock: fix spin_unlock_wait for LSE atomics Will Deacon
2016-06-08 16:25 ` [PATCH v2 3/3] arm64: spinlock: use lock->owner to optimise spin_unlock_wait Will Deacon
2016-06-10 12:25 ` Peter Zijlstra
2016-06-10 12:46 ` Will Deacon
2016-06-10 13:13 ` Peter Zijlstra [this message]
2016-06-10 13:36 ` [PATCH v2 1/3] arm64: spinlock: order spin_{is_locked, unlock_wait} against local locks Mark Rutland
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=20160610131336.GD30154@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.