lkml.org 
[lkml]   [2018]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test
On Thu, Feb 22, 2018 at 11:15:04AM +0100, Peter Zijlstra wrote:
> On Thu, Feb 22, 2018 at 02:58:47PM +0800, Boqun Feng wrote:
> > > And yes, if we go with a purely RCpc interpretation of acquire and
> > > release, then I don't believe the writes in the previous critical
> > > section would be ordered with the writes in the subsequent critical
> > > section. That's really all the argument boils down to. We'd like
> >
> > I think atomics in Linux kernel(and in LKMM) are purely RCpc, right?
> > Alan and Andrea?
> >
> > And we are not going to change it, are we?
> >
> > If atomics in Linux kernel are purely RCpc, then it cerntainly makes
> > sense for riscv to provide purely RCpc atomics.
>
> So there's 3 things:
>
> smp_load_acquire(), smp_store_release()
>
> atomic*_{acquire,release}()
>
> *_{lock,unlock}();
>
> Which are all quite distinct.
>
> smp_load_acquire() and smp_store_release() are RCpc, and there is no
> discussion of ever wanting to change that.
>
> The atomics also follow this and are RCpc, in fact the RELEASE only
> applies to the STORE and the ACQUIRE only applies to the LOAD of the
> atomics.
>
> The locking primitives OTOH we would really rather like to be RCsc, and
> everybody except PPC has them as such, PPC being the only one having
> RCpc locks.
>
> I read the part you quoted from Daniel as being purely about spinlocks,
> the 'critical section' wording being a dead give away, so I'm then
> somewhat confused why you talk about atomics.

Maybe it's me who misunderstand Daniel's words. But my understanding is
that riscv people are on a debate about whether their "RCpc" atomic
instructions need to be more strict: release+acquire pair orders two
writes. And I thought that atomics(including RmW atomics) in kernel only
have purely RCpc semantics, which I needed to check with you guy. And if
I'm right, it's cerntainly fine for riscv "RCpc" instruction to be
purely RCpc.

Note that even on PPC, the release+acquire pair of atomics orders writes
before and after, and on x86, writes are ordered since it's TSO. So
strictly speaking, I think our current implementation of atomics are a
little more strict than purely RCpc. If we think this is an requirement
for implementation of atomic primitives, than the current version of
riscv's "RCpc" atomics don't suffice.

Regards,
Boqun
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2018-02-22 11:42    [W:0.075 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site