Hi Andrii, On Fri, May 22, 2020 at 12:38:21PM -0700, Andrii Nakryiko wrote: > On 5/22/20 10:43 AM, Paul E. McKenney wrote: > > On Fri, May 22, 2020 at 10:32:01AM -0400, Alan Stern wrote: > > > On Fri, May 22, 2020 at 11:44:07AM +0200, Peter Zijlstra wrote: > > > > On Thu, May 21, 2020 at 05:38:50PM -0700, Paul E. McKenney wrote: > > > > > Hello! > > > > > > > > > > Just wanted to call your attention to some pretty cool and pretty serious > > > > > litmus tests that Andrii did as part of his BPF ring-buffer work: > > > > > > > > > > https://lore.kernel.org/bpf/20200517195727.279322-3-andriin@xxxxxx/ > > > > > > > > > > Thoughts? > > > > > > > > I find: > > > > > > > > smp_wmb() > > > > smp_store_release() > > > > > > > > a _very_ weird construct. What is that supposed to even do? > > > > > > Indeed, it looks like one or the other of those is redundant (depending > > > on the context). > > > > Probably. Peter instead asked what it was supposed to even do. ;-) > > I agree, I think smp_wmb() is redundant here. Can't remember why I thought > that it's necessary, this algorithm went through a bunch of iterations, > starting as completely lockless, also using READ_ONCE/WRITE_ONCE at some > point, and settling on smp_read_acquire/smp_store_release, eventually. Maybe > there was some reason, but might be that I was just over-cautious. See reply > on patch thread as well ([0]). > > [0] https://lore.kernel.org/bpf/CAEf4Bza26AbRMtWcoD5+TFhnmnU6p5YJ8zO+SoAJCDtp1jVhcQ@xxxxxxxxxxxxxx/ > While we are at it, could you explain a bit on why you use smp_store_release() on consumer_pos? I ask because IIUC, consumer_pos is only updated at consumer side, and there is no other write at consumer side that we want to order with the write to consumer_pos. So I fail to find why smp_store_release() is necessary. I did the following modification on litmus tests, and I didn't see different results (on States) between two versions of litmus tests. Regards, Boqun ---------------------->8 diff --git a/tools/memory-model/litmus-tests/mpsc-rb+1p1c+bounded.litmus b/tools/memory-model/litmus-tests/mpsc-rb+1p1c+bounded.litmus index cafd17afe11e..255b23be7fa9 100644 --- a/tools/memory-model/litmus-tests/mpsc-rb+1p1c+bounded.litmus +++ b/tools/memory-model/litmus-tests/mpsc-rb+1p1c+bounded.litmus @@ -46,7 +46,7 @@ P0(int *len1, int *cx, int *px) rFail = 1; } else if (rLen == 1) { rCx = rCx + 1; - smp_store_release(cx, rCx); + WRITE_ONCE(*cx, rCx); } } } diff --git a/tools/memory-model/litmus-tests/mpsc-rb+1p1c+unbound.litmus b/tools/memory-model/litmus-tests/mpsc-rb+1p1c+unbound.litmus index 84f660598015..5eecf14f87d1 100644 --- a/tools/memory-model/litmus-tests/mpsc-rb+1p1c+unbound.litmus +++ b/tools/memory-model/litmus-tests/mpsc-rb+1p1c+unbound.litmus @@ -44,7 +44,7 @@ P0(int *len1, int *cx, int *px) rFail = 1; } else if (rLen == 1) { rCx = rCx + 1; - smp_store_release(cx, rCx); + WRITE_ONCE(*cx, rCx); } } } diff --git a/tools/memory-model/litmus-tests/mpsc-rb+2p1c+bounded.litmus b/tools/memory-model/litmus-tests/mpsc-rb+2p1c+bounded.litmus index 900104c4933b..54da1e5d7ec0 100644 --- a/tools/memory-model/litmus-tests/mpsc-rb+2p1c+bounded.litmus +++ b/tools/memory-model/litmus-tests/mpsc-rb+2p1c+bounded.litmus @@ -50,7 +50,7 @@ P0(int *len1, int *cx, int *px) rFail = 1; } else if (rLen == 1) { rCx = rCx + 1; - smp_store_release(cx, rCx); + WRITE_ONCE(*cx, rCx); } } @@ -68,7 +68,7 @@ P0(int *len1, int *cx, int *px) rFail = 1; } else if (rLen == 1) { rCx = rCx + 1; - smp_store_release(cx, rCx); + WRITE_ONCE(*cx, rCx); } } } diff --git a/tools/memory-model/litmus-tests/mpsc-rb+2p1c+unbound.litmus b/tools/memory-model/litmus-tests/mpsc-rb+2p1c+unbound.litmus index 83372e9eb079..fd19433f4d9b 100644 --- a/tools/memory-model/litmus-tests/mpsc-rb+2p1c+unbound.litmus +++ b/tools/memory-model/litmus-tests/mpsc-rb+2p1c+unbound.litmus @@ -47,7 +47,7 @@ P0(int *len1, int *len2, int *cx, int *px) rFail = 1; } else if (rLen == 1) { rCx = rCx + 1; - smp_store_release(cx, rCx); + WRITE_ONCE(*cx, rCx); } } @@ -65,7 +65,7 @@ P0(int *len1, int *len2, int *cx, int *px) rFail = 1; } else if (rLen == 1) { rCx = rCx + 1; - smp_store_release(cx, rCx); + WRITE_ONCE(*cx, rCx); } } } > > > > > > Also, what use is a spinlock that is accessed in only one thread? > > > > Multiple writers synchronize via the spinlock in this case. I am > > guessing that his larger 16-hour test contended this spinlock. > > Yes, spinlock is for coordinating multiple producers. 2p1c cases (bounded > and unbounded) rely on this already. 1p1c cases are sort of subsets (but > very fast to verify) checking only consumer/producer interaction. > > > > > > Finally, I doubt that these tests belong under tools/memory-model. > > > Shouldn't they go under the new Documentation/ directory for litmus > > > tests? And shouldn't the patch update a README file? > > > > Agreed, and I responded to that effect to his original patch: > > > > https://lore.kernel.org/bpf/20200522003433.GG2869@paulmck-ThinkPad-P72/ > > Yep, makes sense, I'll will move. > > > > > Thanx, Paul > > >
Attachment:
signature.asc
Description: PGP signature
