From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Andrea Parri <andrea.parri@amarulasolutions.com>
Cc: Daniel Lustig <dlustig@nvidia.com>,
Will Deacon <will.deacon@arm.com>,
Alan Stern <stern@rowland.harvard.edu>,
LKMM Maintainers -- Akira Yokosawa <akiyks@gmail.com>,
Boqun Feng <boqun.feng@gmail.com>,
David Howells <dhowells@redhat.com>,
Jade Alglave <j.alglave@ucl.ac.uk>,
Luc Maranget <luc.maranget@inria.fr>,
Nicholas Piggin <npiggin@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks
Date: Thu, 5 Jul 2018 16:31:24 -0700 [thread overview]
Message-ID: <20180705233124.GX3593@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180705183836.GA3175@andrea>
On Thu, Jul 05, 2018 at 08:38:36PM +0200, Andrea Parri wrote:
> > No, I'm definitely not pushing for anything stronger. I'm still just
> > wondering if the name "RCsc" is right for what you described. For
> > example, Andrea just said this in a parallel email:
> >
> > > "RCsc" as ordering everything except for W -> R, without the [extra]
> > > barriers
>
> And I already regret it: the point is, different communities/people have
> different things in mind when they use terms such as "RCsc" or "ordering"
> and different communities seems to be represented in LKMM.
How about "RCsb" for release-consistency store buffering? (Sorry,
couldn't resist...)
> Really, I don't think that this is simply a matter of naming (personally,
> I'd be OK with "foo" or whather you suggested below! ;-)). My suggestion
> would be: "get in there!! ;-) please let's refrain from using terms such
> as these (_overly_ overloaded) "RCsc" and "order" when talking about MCM
> let's rather talk, say, about "ppo", "cumul-fence" ...
What is in a name? ;-)
Thanx, Paul
> Andrea
>
>
> >
> > If it's "RCsc with exceptions", doesn't it make sense to find a
> > different name, rather than simply overloading the term "RCsc" with
> > a subtly different meaning, and hoping nobody gets confused?
> >
> > I suppose on x86 and ARM you'd happen to get "true RCsc" anyway, just
> > due to the way things are currently mapped: LOCKed RMWs and "true RCsc"
> > instructions, respectively. But on Power and RISC-V, it would really
> > be more "RCsc with a W->R exception", right?
> >
> > In fact, the more I think about it, this doesn't seem to be RCsc at all.
> > It seems closer to "RCpc plus extra PC ordering between critical
> > sections". No?
> >
> > The synchronization accesses themselves aren't sequentially consistent
> > with respect to each other under the Power or RISC-V mappings, unless
> > there's a hwsync in there somewhere that I missed? Or a rule
> > preventing stw from forwarding to lwarx? Or some other higher-order
> > effect preventing it from being observed anyway?
> >
> > So that's all I'm suggesting here. If you all buy that, maybe "RCpccs"
> > for "RCpc with processor consistent critical section ordering"?
> > I don't have a strong opinion on the name itself; I just want to find
> > a name that's less ambiguous or overloaded.
> >
> > Dan
>
next prev parent reply other threads:[~2018-07-05 23:29 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-21 17:27 [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks Alan Stern
2018-06-21 18:04 ` Peter Zijlstra
2018-06-22 3:34 ` Paul E. McKenney
2018-06-22 8:08 ` Peter Zijlstra
2018-06-22 8:09 ` Will Deacon
2018-06-22 9:55 ` Will Deacon
2018-06-22 10:31 ` Peter Zijlstra
2018-06-22 10:38 ` Will Deacon
2018-06-22 11:25 ` Andrea Parri
2018-06-22 16:40 ` Paul E. McKenney
2018-06-22 18:09 ` Alan Stern
2018-06-22 18:30 ` Will Deacon
2018-06-22 19:11 ` Alan Stern
2018-06-22 20:53 ` Paul E. McKenney
2018-07-04 11:53 ` Will Deacon
2018-06-25 8:19 ` Andrea Parri
2018-07-03 17:28 ` Alan Stern
2018-07-04 11:28 ` Paul E. McKenney
2018-07-04 12:13 ` Will Deacon
2018-07-05 14:23 ` Alan Stern
2018-07-05 15:31 ` Paul E. McKenney
2018-07-04 12:11 ` Will Deacon
2018-07-05 14:00 ` Andrea Parri
2018-07-05 14:44 ` Will Deacon
2018-07-05 15:16 ` Daniel Lustig
2018-07-05 15:35 ` Daniel Lustig
2018-07-05 14:21 ` Alan Stern
2018-07-05 14:46 ` Will Deacon
2018-07-05 14:57 ` Alan Stern
2018-07-05 15:15 ` Will Deacon
2018-07-05 15:09 ` Andrea Parri
2018-07-06 20:37 ` Alan Stern
2018-07-06 21:10 ` Paul E. McKenney
2018-07-09 16:52 ` Will Deacon
2018-07-09 17:29 ` Daniel Lustig
2018-07-09 19:18 ` Alan Stern
2018-07-05 15:31 ` Paul E. McKenney
2018-07-05 15:39 ` Andrea Parri
2018-07-05 16:58 ` Paul E. McKenney
2018-07-05 17:06 ` Andrea Parri
2018-07-05 15:44 ` Daniel Lustig
2018-07-05 16:22 ` Will Deacon
2018-07-05 16:56 ` Paul E. McKenney
2018-07-05 18:12 ` Daniel Lustig
2018-07-05 18:38 ` Andrea Parri
2018-07-05 18:44 ` Andrea Parri
2018-07-05 23:32 ` Paul E. McKenney
2018-07-05 23:31 ` Paul E. McKenney [this message]
2018-07-06 9:25 ` Will Deacon
2018-07-06 14:14 ` Paul E. McKenney
2018-06-25 7:32 ` Peter Zijlstra
2018-06-25 8:29 ` Andrea Parri
2018-06-25 9:06 ` Peter Zijlstra
2018-06-22 9:06 ` Andrea Parri
2018-06-22 19:23 ` Alan Stern
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=20180705233124.GX3593@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akiyks@gmail.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=j.alglave@ucl.ac.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=will.deacon@arm.com \
/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.