lkml.org 
[lkml]   [2015]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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 :-)


\
 
 \ /
  Last update: 2015-02-17 19:41    [W:0.100 / U:2.720 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site