All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2017-11-16 10:25 UTC|newest]

Thread overview: 46+ 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 ` Palmer Dabbelt
2017-09-27  1:56 ` [PATCH v9 02/12] lib: Add shared copies of some GCC library routines Palmer Dabbelt
     [not found] ` <20170927015638.19443-1-palmer-96lFi9zoCfxBDgjK7y7TUQ@public.gmane.org>
2017-09-27  1:56   ` [PATCH v9 01/12] MAINTAINERS: Add RISC-V Palmer Dabbelt
2017-09-27  1:56     ` Palmer Dabbelt
2017-09-27  1:56   ` [PATCH v9 03/12] dt-bindings: RISC-V CPU Bindings Palmer Dabbelt
2017-09-27  1:56     ` Palmer Dabbelt
2017-10-05 10:16     ` Mark Rutland
2017-11-20  7:35       ` [patches] " Jonathan Neuschäfer
2017-11-20  7:35         ` Jonathan Neuschäfer
2017-11-20 19:45         ` Palmer Dabbelt
2017-09-27  1:56   ` [PATCH v9 05/12] RISC-V: Atomic and Locking Code Palmer Dabbelt
2017-09-27  1:56     ` Palmer Dabbelt
     [not found]     ` <20170927015638.19443-6-palmer-96lFi9zoCfxBDgjK7y7TUQ@public.gmane.org>
2017-10-24 14:10       ` Will Deacon
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 10/12] RISC-V: Paging and MMU Palmer Dabbelt
2017-09-27  1:56     ` Palmer Dabbelt
2017-09-27  1:56   ` [PATCH v9 12/12] RISC-V: Build Infrastructure Palmer Dabbelt
2017-09-27  1:56     ` 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-30 23:42       ` Palmer Dabbelt
2018-07-31 13:03       ` Mark Rutland
2018-07-31 13:03         ` Mark Rutland
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 11/12] RISC-V: User-facing API Palmer Dabbelt
2017-09-27  6:08 ` RISC-V Linux Port v9 Arnd Bergmann
     [not found]   ` <CAK8P3a1ROLHHY9HE0LtPywhTMqBaHjp8kd4ZVBr3iWTyveBh9A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-10-05  0:21     ` Palmer Dabbelt
2017-10-05  0:21       ` Palmer Dabbelt
2017-10-05  7:34       ` Arnd Bergmann
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 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.