From: Will Deacon <will.deacon@arm.com>
To: Daniel Lustig <dlustig@nvidia.com>
Cc: Boqun Feng <boqun.feng@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"patches@groups.riscv.org" <patches@groups.riscv.org>,
"peterz@infradead.org" <peterz@infradead.org>
Subject: Re: [patches] Re: [PATCH v9 05/12] RISC-V: Atomic and Locking Code
Date: Thu, 16 Nov 2017 10:25:46 +0000 [thread overview]
Message-ID: <20171116102545.GA9361@arm.com> (raw)
In-Reply-To: <2965fc412451432db276d561d47902fb@HQMAIL105.nvidia.com>
Hi Daniel,
On Thu, Nov 16, 2017 at 06:40:46AM +0000, Daniel Lustig wrote:
> > > In that case, maybe we should just start out having a fence on both
> > > sides for
> >
> > Actually, given your architecture is RCsc rather than RCpc, so I think maybe
> > you could follow the way that ARM uses(i.e. relaxed load + release store + a
> > full barrier). You can see the commit log of 8e86f0b409a4
> > ("arm64: atomics: fix use of acquire + release for full barrier
> > semantics") for the reasoning:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co
> > mmit/?id=8e86f0b409a44193f1587e87b69c5dcf8f65be67
>
> OK I'm catching up now...and I have to say, that is clever! Thanks for the
> corrections. It would definitely be good to avoid the double fence. Let me
> think this over a bit more.
>
> One subtle point about RCpc vs. RCsc, though: see below.
>
> >
> > Sounds great! Any estimation when we can see that(maybe a draft)?
>
> The latest should be November 28-30, coinciding with the next RISC-V workshop.
> Possibly even sooner. We just recently resolved a big debate that's been
> holding us up for a while, and so now it's just a matter of me writing it all
> up so it's understandable.
>
> In the meantime, though, let me quickly and informally summarize some of the
> highlights, in case it helps unblock any further review here:
>
> - The model is now (other-)multi-copy atomic
> - .aq and .rl alone mean RCpc
> - .aqrl means RCsc
That presents you with an interesting choice when implementing locks: do you
use .aqrl for lock and unlokc and elide smp_mb__after_spinlock, or do you use
.aq/.rl for lock/unlock respectively and emit a fence for
smp_mb__after_spinlock?
> - .aq applies only to the read part of an RMW
> - .rl applies only to the write part of an RMW
> - Syntactic dependencies are now respected
Thanks for the update, even this brief summary is better than the current
architecture document ;)
> I recognize this isn't enough detail to do it proper justice, but we'll get the
> full model out as soon as we can.
Ok, I'll bite! Do you forbid LB?
Will
next prev parent reply other threads:[~2017-11-16 10:25 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-27 1:56 RISC-V Linux Port v9 Palmer Dabbelt
2017-09-27 1:56 ` [PATCH v9 01/12] MAINTAINERS: Add RISC-V Palmer Dabbelt
2017-09-27 1:56 ` [PATCH v9 02/12] lib: Add shared copies of some GCC library routines Palmer Dabbelt
2017-09-27 1:56 ` [PATCH v9 03/12] dt-bindings: RISC-V CPU Bindings Palmer Dabbelt
2017-10-05 10:16 ` Mark Rutland
2017-11-20 7:35 ` [patches] " Jonathan Neuschäfer
2017-11-20 19:45 ` Palmer Dabbelt
2017-09-27 1:56 ` [PATCH v9 04/12] RISC-V: Init and Halt Code Palmer Dabbelt
2017-10-05 11:01 ` Mark Rutland
2018-07-30 23:42 ` Palmer Dabbelt
2018-07-31 13:03 ` Mark Rutland
2017-09-27 1:56 ` [PATCH v9 05/12] RISC-V: Atomic and Locking Code Palmer Dabbelt
2017-10-24 14:10 ` Will Deacon
2017-11-14 20:30 ` Palmer Dabbelt
2017-11-15 18:06 ` Will Deacon
2017-11-15 19:48 ` [patches] " Palmer Dabbelt
2017-11-15 23:59 ` Daniel Lustig
2017-11-16 1:19 ` Boqun Feng
2017-11-16 1:31 ` Daniel Lustig
2017-11-16 1:52 ` Boqun Feng
2017-11-16 6:40 ` Daniel Lustig
2017-11-16 10:25 ` Will Deacon [this message]
2017-11-16 17:12 ` Daniel Lustig
2017-11-16 2:08 ` Palmer Dabbelt
2017-09-27 1:56 ` [PATCH v9 06/12] RISC-V: Generic library routines and assembly Palmer Dabbelt
2017-09-27 1:56 ` [PATCH v9 07/12] RISC-V: ELF and module implementation Palmer Dabbelt
2017-09-27 1:56 ` [PATCH v9 08/12] RISC-V: Task implementation Palmer Dabbelt
2017-09-27 1:56 ` [PATCH v9 09/12] RISC-V: Device, timer, IRQs, and the SBI Palmer Dabbelt
2017-09-27 1:56 ` [PATCH v9 10/12] RISC-V: Paging and MMU Palmer Dabbelt
2017-09-27 1:56 ` [PATCH v9 11/12] RISC-V: User-facing API Palmer Dabbelt
2017-09-27 1:56 ` [PATCH v9 12/12] RISC-V: Build Infrastructure Palmer Dabbelt
2017-09-27 6:08 ` RISC-V Linux Port v9 Arnd Bergmann
2017-10-05 0:21 ` Palmer Dabbelt
2017-10-05 7:34 ` Arnd Bergmann
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=20171116102545.GA9361@arm.com \
--to=will.deacon@arm.com \
--cc=arnd@arndb.de \
--cc=boqun.feng@gmail.com \
--cc=dlustig@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olof@lixom.net \
--cc=palmer@dabbelt.com \
--cc=patches@groups.riscv.org \
--cc=peterz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome