From: Will Deacon <will.deacon@arm.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: David Miller <davem@davemloft.net>,
torvalds@linux-foundation.org, linux-arch@vger.kernel.org,
linux-kernel@vger.kernel.org, anton@samba.org,
linuxppc-dev@ozlabs.org, peterz@infradead.org
Subject: Re: [RFC][PATCH] spin loop arch primitives for busy waiting
Date: Thu, 6 Apr 2017 15:13:53 +0100 [thread overview]
Message-ID: <20170406141352.GF18204@arm.com> (raw)
In-Reply-To: <20170406105958.196c6977@roar.ozlabs.ibm.com>
Hi Nick,
On Thu, Apr 06, 2017 at 10:59:58AM +1000, Nicholas Piggin wrote:
> On Wed, 05 Apr 2017 07:01:57 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
> > From: Nicholas Piggin <npiggin@gmail.com>
> > Date: Tue, 4 Apr 2017 13:02:33 +1000
> >
> > > On Mon, 3 Apr 2017 17:43:05 -0700
> > > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > >
> > >> But that depends on architectures having some pattern that we *can*
> > >> abstract. Would some "begin/in-loop/end" pattern like the above be
> > >> sufficient?
> > >
> > > Yes. begin/in/end would be sufficient for powerpc SMT priority, and
> > > for x86, and it looks like sparc64 too. So we could do that if you
> > > prefer.
> >
> > Sparc64 has two cases, on older chips we can induce a cpu thread yield
> > with a special sequence of instructions, and on newer chips we have
> > a bonafide pause instruction.
> >
> > So cpu_relax() all by itself pretty much works for us.
> >
>
> Thanks for taking a look. The default spin primitives should just
> continue to do the right thing for you in that case.
>
> Arm has a yield instruction, ia64 has a pause... No unusual
> requirements that I can see.
Yield tends to be implemented as a NOP in practice, since it's in the
architecture for SMT CPUs and most ARM CPUs are single-threaded. We do have
the WFE instruction (wait for event) which is used in our implementation of
smp_cond_load_acquire, but I don't think we'd be able to use it with the
proposals here.
WFE can stop the clock for the CPU until an "event" is signalled by
another CPU. This could be done by an explicit SEV (send event) instruction,
but that tends to require heavy barriers on the signalling side. Instead,
the preferred way to generate an event is to clear the exclusive monitor
reservation for the CPU executing the WFE. That means that the waiter
does something like:
LDXR x0, [some_address] // Load exclusive from some_address
CMP x0, some value // If the value matches what I want
B.EQ out // then we're done
WFE // otherwise, wait
at this point, the waiter will stop on the WFE until its monitor is cleared,
which happens if another CPU writes to some_address.
We've wrapped this up in the arm64 code as __cmpwait, and we use that
to build smp_cond_load_acquire. It would be nice to use the same machinery
for the conditional spinning here, unless you anticipate that we're only
going to be spinning for a handful of iterations anyway?
Cheers,
Will
next prev parent reply other threads:[~2017-04-06 14:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-03 8:13 [RFC][PATCH] spin loop arch primitives for busy waiting Nicholas Piggin
2017-04-03 8:13 ` Nicholas Piggin
2017-04-03 15:31 ` Linus Torvalds
2017-04-03 15:31 ` Linus Torvalds
2017-04-03 23:50 ` Nicholas Piggin
2017-04-04 0:43 ` Linus Torvalds
2017-04-04 3:02 ` Nicholas Piggin
2017-04-04 4:11 ` Nicholas Piggin
2017-04-05 14:01 ` David Miller
2017-04-05 14:01 ` David Miller
2017-04-06 0:59 ` Nicholas Piggin
2017-04-06 14:13 ` Will Deacon [this message]
2017-04-06 14:13 ` Will Deacon
2017-04-06 15:16 ` Linus Torvalds
2017-04-06 16:36 ` Peter Zijlstra
2017-04-06 17:31 ` Linus Torvalds
2017-04-06 19:23 ` Peter Zijlstra
2017-04-06 19:41 ` Linus Torvalds
2017-04-07 3:31 ` Nicholas Piggin
2017-04-07 9:43 ` Peter Zijlstra
2017-04-07 11:26 ` Nicholas Piggin
2017-04-06 15:30 ` Nicholas Piggin
2017-04-07 16:13 ` Will Deacon
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=20170406141352.GF18204@arm.com \
--to=will.deacon@arm.com \
--cc=anton@samba.org \
--cc=davem@davemloft.net \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.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 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).