Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1736823
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Memory-ordering recipes |
| Date | 2017-09-21 18:20 +0200 |
| Message-ID | <uscmJ-3iX-11@gated-at.bofh.it> (permalink) |
| References | <uqQRj-6bH-5@gated-at.bofh.it> <us95w-13h-17@gated-at.bofh.it> <usbAm-2Ne-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Sep 21, 2017 at 08:26:42AM -0700, Paul E. McKenney wrote: > ISA2 is the first one on page 2, and has this pattern of reads and > writes: > > CPU 0 CPU 1 CPU 2 > > WRITE_ONCE(x, 1); r1 = READ_ONCE(y); r2 = READ_ONCE(z); > WRITE_ONCE(y, 1); WRITE_ONCE(z, 1); r3 = READ_ONCE(x); > > BUG_ON(r1 == 1 && r2 == 1 && r3 == 0); > > Arbitrary ordering can be added to all of these litmus-test patterns, > for example, the writes to y and z might become smp_store_release() > and the read from z might become smp_load_acquire(). Or, alternatively, > smp_mb() might be placed between accesses on all thread CPUs. The key > point is that "ISA2" identifies not a specific litmus test, but instead a > family of them with the same pattern of reads, writes and RMW operations, > but with different ordering properties. > > Z6.3 is the second one on page 2: > > CPU 0 CPU 1 CPU 2 > > WRITE_ONCE(x, 2); r1 = READ_ONCE(y); r2 = READ_ONCE(z); > WRITE_ONCE(y, 1); WRITE_ONCE(z, 1); WRITE_ONCE(x, 1); > > BUG_ON(r1 == 1 && r2 == 1 && x == 2); But why are these useful to include in a recipes list? I would imagine those should cover the simple 2 threads stuff. Once you go fancy and need 3 CPUs I feel people had better know wth they're on about. > LB is the last on on the extreme left of page 1. "LB" stands for > "load buffering", and each CPU's first access is a load and last > access is a store: > > CPU 0 CPU 1 > > r1 = READ_ONCE(x); r2 = READ_ONCE(y); > WRITE_ONCE(y, 1); WRITE_ONCE(x, 1); > > BUG_ON(r1 == 1 && r2 == 1); > MP is the second on the extreme left of page 1. "MP" stands for "message > passing", and is used very heavily. The idea is that "x" is the message > (sent by CPU 0), and "y" is a flag saying that the message is ready to > be received (by CPU 1). > > CPU 0 CPU 1 > > WRITE_ONCE(x, 1); r1 = READ_ONCE(y); > WRITE_ONCE(y, 1); r1 = READ_ONCE(x); > > BUG_ON(r1 == 1 && r2 == 0); Right, these two are fairly common patterns. > SB is the fourth on the extreme left of page 1. "SB" stands for "store > buffering" because systems without store buffers won't reorder this one. > > CPU 0 CPU 1 > > WRITE_ONCE(x, 1); WRITE_ONCE(y, 1); > r1 = READ_ONCE(y); r2 = READ_ONCE(x); > > BUG_ON(r1 == 0 && r2 == 0); > > Does that help? > > Oh, and the actual recipes would include ordering as indicated by > the sub-bullets. Which just generates a terrible lot of noise. Why would people be interested in these permutations? Why not the minimal set that makes the guarantee? Also, none of these cover 'simple' stuff like a ring-buffer. So I have to ask, what is the purpose of this recipes list?
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Memory-ordering recipes "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-09-18 01:10 +0200
Re: Memory-ordering recipes Boqun Feng <boqun.feng@gmail.com> - 2017-09-18 10:00 +0200
Re: Memory-ordering recipes "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-09-18 16:30 +0200
Re: Memory-ordering recipes Boqun Feng <boqun.feng@gmail.com> - 2017-09-19 04:10 +0200
Re: Memory-ordering recipes Peter Zijlstra <peterz@infradead.org> - 2017-09-21 14:50 +0200
Re: Memory-ordering recipes "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-09-21 17:30 +0200
Re: Memory-ordering recipes Peter Zijlstra <peterz@infradead.org> - 2017-09-21 18:20 +0200
Re: Memory-ordering recipes "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-09-21 18:50 +0200
Re: Memory-ordering recipes Peter Zijlstra <peterz@infradead.org> - 2017-09-22 11:30 +0200
Re: Memory-ordering recipes "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-09-22 23:10 +0200
csiph-web