search for: ppcmem

...If you think of it as a cycle, then it doesn't matter where the local link is, just how many of them and how they are connected. But I will admit that there are some rather strange litmus tests that challenge this cycle-centric view, for example, the one shown below. It turns out that herd and ppcmem disagree on the outcome. (The Power architects side with ppcmem.) > And I think I'm still confused on LWSYNC (in the smp_wmb case) when one > of the stores looses a conflict, and if that scenario matters. If it > does, we should inspect the same case for other barriers. Indeed. I a...

...If you think of it as a cycle, then it doesn't matter where the local link is, just how many of them and how they are connected. But I will admit that there are some rather strange litmus tests that challenge this cycle-centric view, for example, the one shown below. It turns out that herd and ppcmem disagree on the outcome. (The Power architects side with ppcmem.) > And I think I'm still confused on LWSYNC (in the smp_wmb case) when one > of the stores looses a conflict, and if that scenario matters. If it > does, we should inspect the same case for other barriers. Indeed. I a...

...> What else do you want from me - RTL or microArch design for that? I suspect that it is more likely that we are talking past each other. This stuff is subtle and although we have better ways of talking about it than (say) ten years ago, it is subtle. Two ways of talking about it are herd and ppcmem. The overview of ppcmem (AKA armmem and cppmem) is here: https://www.cl.cam.ac.uk/~pes20/ppcmem/help.html The intro to herd is here: http://arxiv.org/pdf/1308.6810v5.pdf It may be downloaded here: http://diy.inria.fr/herd/ As a very rough rule of thumb, herd is faster and easier to use and ppcme...

...{ > > r2 = lockless_dereference(y.next); > > r3 = READ_ONCE(r2->next); > > } > > > > In this case, it is legal to end the run with: > > > > r1 == &y && r2 == &x && r3 == &c > > > > Please see below for a ppcmem litmus test. > > > > So, did I get it right this time? ;-) > > The code above looks correct to me (in that it matches WRC+addrs), > but your litmus test: > > > PPC WRCnf+addrs > > "" > > { > > 0:r2=x; 0:r3=y; > > 1:r2=x; 1:r3=y; &g...

...{ > > r2 = lockless_dereference(y.next); > > r3 = READ_ONCE(r2->next); > > } > > > > In this case, it is legal to end the run with: > > > > r1 == &y && r2 == &x && r3 == &c > > > > Please see below for a ppcmem litmus test. > > > > So, did I get it right this time? ;-) > > The code above looks correct to me (in that it matches WRC+addrs), > but your litmus test: > > > PPC WRCnf+addrs > > "" > > { > > 0:r2=x; 0:r3=y; > > 1:r2=x; 1:r3=y; &g...

On 01/14/2016 04:04 AM, Will Deacon wrote: > Consequently, it's important that the architecture back-ends implement > these portable primitives (e.g. smp_mb()) in a way that satisfies the > kernel memory model so that core code doesn't need to worry about the > underlying architecture for synchronisation purposes. It seems you don't listen me. I said multiple times -

On 01/14/2016 04:04 AM, Will Deacon wrote: > Consequently, it's important that the architecture back-ends implement > these portable primitives (e.g. smp_mb()) in a way that satisfies the > kernel memory model so that core code doesn't need to worry about the > underlying architecture for synchronisation purposes. It seems you don't listen me. I said multiple times -

...9;m struggling to make it work in my mind, or are you talking specifically in the context of the kernel memory model? > But I will admit that there are some rather strange litmus tests that > challenge this cycle-centric view, for example, the one shown below. > It turns out that herd and ppcmem disagree on the outcome. (The Power > architects side with ppcmem.) > > > And I think I'm still confused on LWSYNC (in the smp_wmb case) when one > > of the stores looses a conflict, and if that scenario matters. If it > > does, we should inspect the same case for othe...

...use it might be possible to deal with does not necessarily mean that we should be encouraging it. ;-) > > But I will admit that there are some rather strange litmus tests that > > challenge this cycle-centric view, for example, the one shown below. > > It turns out that herd and ppcmem disagree on the outcome. (The Power > > architects side with ppcmem.) > > > > > And I think I'm still confused on LWSYNC (in the smp_wmb case) when one > > > of the stores looses a conflict, and if that scenario matters. If it > > > does, we should inspe...

...use it might be possible to deal with does not necessarily mean that we should be encouraging it. ;-) > > But I will admit that there are some rather strange litmus tests that > > challenge this cycle-centric view, for example, the one shown below. > > It turns out that herd and ppcmem disagree on the outcome. (The Power > > architects side with ppcmem.) > > > > > And I think I'm still confused on LWSYNC (in the smp_wmb case) when one > > > of the stores looses a conflict, and if that scenario matters. If it > > > does, we should inspe...

...r1 = lockless_dereference(x.next); WRITE_ONCE(r1->next, &x); } void cpu2(void) { r2 = lockless_dereference(y.next); r3 = READ_ONCE(r2->next); } In this case, it is legal to end the run with: r1 == &y && r2 == &x && r3 == &c Please see below for a ppcmem litmus test. So, did I get it right this time? ;-) Thanx, Paul PS. And yes, working through this does help me understand the benefits of fake dependencies. Why do you ask? ;-) ------------------------------------------------------------------------ PPC WRCnf+addrs ""...

...r1 = lockless_dereference(x.next); WRITE_ONCE(r1->next, &x); } void cpu2(void) { r2 = lockless_dereference(y.next); r3 = READ_ONCE(r2->next); } In this case, it is legal to end the run with: r1 == &y && r2 == &x && r3 == &c Please see below for a ppcmem litmus test. So, did I get it right this time? ;-) Thanx, Paul PS. And yes, working through this does help me understand the benefits of fake dependencies. Why do you ask? ;-) ------------------------------------------------------------------------ PPC WRCnf+addrs ""...

On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote: > On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote: > > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > > > So smp_mb() provides transitivity, as do pairs of smp_store_release() > > > and smp_read_acquire(), > > > > But they provide different grades of

On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote: > On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote: > > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > > > So smp_mb() provides transitivity, as do pairs of smp_store_release() > > > and smp_read_acquire(), > > > > But they provide different grades of

...; > > > > > > > P0 P1 P2 > > > > Rx=1 Wy=1 Wz=2 > > > > dep. lwsync lwsync > > > > Ry=0 Wz=1 Wx=1 > > > > Rz=1 > > > > > > > > assert(!(z=2)) > > > > > > > > Forbidden by ppcmem, allowed by herd. > > > > *) > > > > { > > > > 0:r1=x; 0:r2=y; 0:r3=z; > > > > 1:r1=x; 1:r2=y; 1:r3=z; 1:r4=1; > > > > 2:r1=x; 2:r2=y; 2:r3=z; 2:r4=1; 2:r5=2; > > > > } > > > > P0 | P1 | P2 ; > > > >...

...; > > > > > > > P0 P1 P2 > > > > Rx=1 Wy=1 Wz=2 > > > > dep. lwsync lwsync > > > > Ry=0 Wz=1 Wx=1 > > > > Rz=1 > > > > > > > > assert(!(z=2)) > > > > > > > > Forbidden by ppcmem, allowed by herd. > > > > *) > > > > { > > > > 0:r1=x; 0:r2=y; 0:r3=z; > > > > 1:r1=x; 1:r2=y; 1:r3=z; 1:r4=1; > > > > 2:r1=x; 2:r2=y; 2:r3=z; 2:r4=1; 2:r5=2; > > > > } > > > > P0 | P1 | P2 ; > > > >...

...e(y.next); > > > r3 = READ_ONCE(r2->next); > > > } > > > > > > In this case, it is legal to end the run with: > > > > > > r1 == &y && r2 == &x && r3 == &c > > > > > > Please see below for a ppcmem litmus test. > > > > > > So, did I get it right this time? ;-) > > > > The code above looks correct to me (in that it matches WRC+addrs), > > but your litmus test: > > > > > PPC WRCnf+addrs > > > "" > > > { > >...

...tly wrote: "In particular we're very much all > 'confused' about the various notions of transitivity". I am confused > too, so - please use some more simple way to explain your words. > Sorry, but we need a common ground first. OK, how about an example? (Z6.3 in the ppcmem naming scheme.) int x, y, z; void cpu0(void) { WRITE_ONCE(x, 1); smp_wmb(); WRITE_ONCE(y, 1); } void cpu1(void) { WRITE_ONCE(y, 2); smp_wmb(); WRITE_ONCE(z, 1); } void cpu2(void) { r1 = READ_ONCE(z); smp_rmb(); r2 = read_once(x); } If smp_rmb() and smp_wmb() provide...

...AD_ONCE(r2->next); > > > > } > > > > > > > > In this case, it is legal to end the run with: > > > > > > > > r1 == &y && r2 == &x && r3 == &c > > > > > > > > Please see below for a ppcmem litmus test. > > > > > > > > So, did I get it right this time? ;-) > > > > > > The code above looks correct to me (in that it matches WRC+addrs), > > > but your litmus test: > > > > > > > PPC WRCnf+addrs > > > >...

...AD_ONCE(r2->next); > > > > } > > > > > > > > In this case, it is legal to end the run with: > > > > > > > > r1 == &y && r2 == &x && r3 == &c > > > > > > > > Please see below for a ppcmem litmus test. > > > > > > > > So, did I get it right this time? ;-) > > > > > > The code above looks correct to me (in that it matches WRC+addrs), > > > but your litmus test: > > > > > > > PPC WRCnf+addrs > > > >...