On Wed, Apr 11, 2018 at 11:00:58AM +0800, Yubin Ruan wrote: > On Wed, Apr 11, 2018 at 10:46:28AM +0800, Yubin Ruan wrote: > > On Tue, Apr 10, 2018 at 10:04:09AM -0700, Paul E. McKenney wrote: > > > On Tue, Apr 10, 2018 at 11:20:24PM +0800, Yubin Ruan wrote: > > > > On Tue, Apr 10, 2018 at 08:14:08PM +0800, Yubin Ruan wrote: > > [...] > > > > > > > > > > Can you please provide me with some examples or references for different kinds > > > > > of memory reordering in a SMP system? You know, there are different kinds of > > > > > reordering: > > > > > > > > > > - Loads reordered after loads > > > > > - Loads reordered after stores > > > > > - Stores reordered after stores > > > > > - Stores reordered after loads > > > > > - Atomic reordered with loads > > > > > - Atomic reordered with stores > > > > > - Dependent loads reordered (DEC alpha) > > > > > > > > I remember there is open-std.org webpage containing comparision of C++'s > > > > memory model to those primitives used in the Linux kernel. But I just can't > > > > find that page. > > > > > > Here you go! > > > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0124r4.html > > > > > > There will be an update in a month or so, but the above is pretty > > > close. Also, the Linux-kernel memory model was presented at > > > ASPLOS and accepted into the Linux kernel itself: > > > > > > https://paulmck.livejournal.com/49667.html > > > > Many thanks. But I am currently confused about the relationship between > > terminologies used in the Linux kernel and those used in some programming > > languages (e.g., C++), i.e., the relationships between > > > > memory_order_release > > memory_order_relaxed > > memory_order_acquire > > memory_order_seq_cst > > ... > > > > and those used in the kernel: > > > > READ_ONCE() / WRITE_ONCE() > > rmb() / wmb() / mb() / smp_mb() > > ... > > > > Any materials for that? > > Hmm, to be more exact, what I want is something like this: > > “These primitives can be expressed directly in terms of the upcoming > C++0x standard. For the smp_mb() primitive this correspondence is not > exact; our memory barriers are somewhat stronger than the standard’s > atomic_thread_fence(memory_order_seq_cst). The LOAD_SHARED() primitive > maps to x.load(memory_order_relaxed) and STORE_SHARED() to > x.store(memory_order_relaxed). The barrier() primitive maps to > atomic_signal_fence(memory_order_seq_cst). In addition, rcu_dereference() > maps to x.load(memory_order_consume) and rcu_assign_pointer() maps to > x.store(v, memory_order_release).” Those are still valid. Again, the other paper from my earlier email has more mappings. > This is extracted from the paper "User-Level Implementations of Read-Copy > Update" by M. Desnoyers and P. McKenney, A. S. Stern, M. R. Dagenais and J. > Walpole[1]. And the LOAD_SHARED() and STORE_SHARED() above are READ_ONCE() and > WRITE_ONCE(), respectively. (BTW, LOAD_SHARED/STORE_SHARED seem to be better > names than READ_ONCE/WRITE_ONCE, which are a bit confusing. How come people > adopted those name?) They came from ACCESS_ONCE(). They are _ONCE() because they prevent the compiler from fusing and splitting accesses, which it can do with normal loads and stores. This Linux Weekly News article has some of this history: http://lwn.net/Articles/508991/ > (I find this after digging into a whole bunch of emails...hmm..email is a good > thing) ;-) ;-) ;-) Thanx, Paul > [1]: https://www.efficios.com/pub/rcu/urcu-main-accepted.pdf > > Yubin > -- To unsubscribe from this list: send the line "unsubscribe perfbook" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
