From: Paolo Bonzini <pbonzini@redhat.com>
To: paulmck@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org,
Alan Stern <stern@rowland.harvard.edu>,
Andrea Parri <parri.andrea@gmail.com>,
Will Deacon <will.deacon@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Nicholas Piggin <npiggin@gmail.com>,
David Howells <dhowells@redhat.com>,
Jade Alglave <j.alglave@ucl.ac.uk>,
Luc Maranget <luc.maranget@inria.fr>,
Akira Yokosawa <akiyks@gmail.com>
Subject: Re: [PATCH] memory-model: fix cheat sheet typo
Date: Wed, 11 Apr 2018 13:15:58 +0200 [thread overview]
Message-ID: <156ac07b-7393-449f-518a-6b1c2cff8efb@redhat.com> (raw)
In-Reply-To: <20180410213434.GC3948@linux.vnet.ibm.com>
On 10/04/2018 23:34, Paul E. McKenney wrote:
> Glad it helps, and I have queued it for the next merge window. Of course,
> if a further improvement comes to mind, please do not keep it a secret. ;-)
Yes, there are several changes that could be included:
- SV could be added to the prior operation case as well? It should be
symmetric
- The *_relaxed() case also applies to void RMW
- smp_store_mb() is missing
- smp_rmb() orders prior reads fully against subsequent RMW because SV
applies between the two parts of the RMW; likewise smp_wmb() orders prior
RMW fully against subsequent writes
I am going submit these changes separately, but before doing that I can show
also my rewrite of the cheat sheet.
The advantage is that, at least to me, it's clearer (and gets rid of
"Self" :)).
The disadvantage is that it's much longer---almost twice the lines, even if
you discount the splitting out of cumulative/propagating to a separate table
(which in turn is because to me it's a different level of black magic).
---------------------
Memory operations are listed in this document as follows:
R: Read portion of RMW
W: Write portion of RMW
DR: Dependent read (address dependency)
DW: Dependent write (address, data, or control dependency)
RMW: Atomic read-modify-write operation
SV Other accesses to the same variable
Memory access operations order other memory operations against themselves as
follows:
Prior Operation Subsequent Operation
--------------- ---------------------
R W RMW SV R W DR DW RMW SV
- - --- -- - - -- -- --- --
Store, e.g., WRITE_ONCE() Y Y
Load, e.g., READ_ONCE() Y Y Y Y
Unsuccessful RMW operation Y Y Y Y
*_relaxed() or void RMW operation Y Y Y Y
rcu_dereference() Y Y Y Y
Successful *_acquire() Y r r r r r Y
Successful *_release() w w w Y Y
smp_store_mb() Y Y Y Y Y Y Y Y Y Y
Successful full non-void RMW Y Y Y Y Y Y Y Y Y Y
Key: Y: Memory operation provides ordering
r: Cannot move past the read portion of the *_acquire()
w: Cannot move past the write portion of the *_release()
Memory barriers order prior memory operations against subsequent memory
operations. Two operations are ordered if both have non-empty cells in
the following table:
Prior Operation Subsequent Operation
--------------- --------------------
R W RMW R W DR DW RMW
- - --- - - -- -- ---
smp_rmb() Y r Y Y Y
smp_wmb() Y Y Y Y w
smp_mb() & synchronize_rcu() Y Y Y Y Y Y Y Y
smp_mb__before_atomic() Y Y Y a a a a Y
smp_mb__after_atomic() a a Y Y Y Y Y
Key: Y: Barrier provides ordering
r: Barrier provides ordering against the read portion of RMW
w: Barrier provides ordering against the write portion of RMW
a: Barrier provides ordering given intervening RMW atomic operation
Finally the following describes which operations provide cumulative and
propagating fences:
Cumulative Propagates
---------- ----------
Store, e.g., WRITE_ONCE()
Load, e.g., READ_ONCE()
Unsuccessful RMW operation
*_relaxed() or void RMW operation
rcu_dereference()
Successful *_acquire()
Successful *_release() Y
smp_store_mb() Y Y
Successful full non-void RMW Y Y
smp_rmb()
smp_wmb()
smp_mb() & synchronize_rcu() Y Y
smp_mb__before_atomic() Y Y
smp_mb__after_atomic() Y Y
----------
Perhaps you can see some obvious improvements. Otherwise I'll send patches
for the above issues.
Thanks,
Paolo
next prev parent reply other threads:[~2018-04-11 11:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-09 16:50 Paolo Bonzini
2018-04-09 18:42 ` Paul E. McKenney
2018-04-10 20:32 ` Paul E. McKenney
2018-04-10 21:10 ` Paolo Bonzini
2018-04-10 21:34 ` Paul E. McKenney
2018-04-11 11:15 ` Paolo Bonzini [this message]
2018-04-11 16:19 ` Paul E. McKenney
2018-04-11 16:31 ` Peter Zijlstra
2018-04-11 17:06 ` Paolo Bonzini
2018-04-12 12:52 ` Boqun Feng
2018-04-12 9:23 ` Andrea Parri
2018-04-12 10:18 ` Paolo Bonzini
2018-04-12 11:21 ` Andrea Parri
2018-04-12 21:18 ` Paul E. McKenney
2018-04-13 9:54 ` Andrea Parri
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=156ac07b-7393-449f-518a-6b1c2cff8efb@redhat.com \
--to=pbonzini@redhat.com \
--cc=akiyks@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=j.alglave@ucl.ac.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®