Messages in this thread |  | | Date | Tue, 17 Feb 2015 19:23:35 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH 2/2] [PATCH] sched: Add smp_rmb() in task rq locking cycles |
| |
On Tue, Feb 17, 2015 at 10:01:54AM -0800, Paul E. McKenney wrote: > > > The blob under SMP BARRIER PAIRING does not mention pairing with control > > > dependencies; and I'm rather sure I've done so. > > And here is a patch for the control-dependency pairing. Thoughts?
The proposed patch does not change the blub under SMP BARRIER PAIRING, which would be the first place I would look for this.
> @@ -850,6 +853,19 @@ Or: > <data dependency barrier> > y = *x; > > +Or even: > + > + CPU 1 CPU 2 > + =============== =============================== > + r1 = ACCESS_ONCE(y); > + <write barrier> > + ACCESS_ONCE(y) = 1; if (r2 = ACCESS_ONCE(x)) { > + <implicit control dependency> > + ACCESS_ONCE(y) = 1; > + } > + > + assert(r1 == 0 || r2 == 0); > + > Basically, the read barrier always has to be there, even though it can be of > the "weaker" type.
Does that want to be a <general barrier>; CPU1 looks to do a LOAD followed by a STORE, separated by a WMB, which is of course odd.
To me the pairing with a general barrier is also the most intuitive, since the control dependency is a LOAD -> STORE order.
Then again, I'm rather tired and maybe I'm missing the obvious :-)
|  |