Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

[Paul E. McKenney]

On Fri, Oct 06, 2017 at 10:15:37PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 06, 2017 at 12:18:22PM -0700, Paul E. McKenney wrote:
> > > /me goes and install this herd thing again.. I'm sure I had it running
> > > _somewhere_.. A well.
> > > 
> > > 	C C-PaulEMcKenney-W+RWC4+2017-10-05
> > > 
> > > 	{
> > > 	}
> > > 
> > > 	P0(int *a, int *x)
> > > 	{
> > > 		WRITE_ONCE(*a, 1);
> > > 		smp_mb(); /* Lock acquisition for rcu_node ->lock. */
> > > 		WRITE_ONCE(*x, 1);
> > > 	}
> > > 
> > > 	P1(int *x, int *y)
> > > 	{
> > > 		r3 = READ_ONCE(*x);
> > > 		smp_mb(); /* Lock acquisition for rcu_node ->lock. */
> > > 		smp_store_release(y, 1);
> > > 	}
> > > 
> > > 	P2(int *y, int *b)
> > > 	{
> > > 		r4 = smp_load_acquire(y);
> > > 		r1 = READ_ONCE(*b);
> > > 	}
> > > 
> > > 	P3(int *b, int *a)
> > > 	{
> > > 		WRITE_ONCE(*b, 1);
> > > 		smp_mb();
> > > 		r2 = READ_ONCE(*a);
> > > 	}
> > > 
> > > 	exists (1:r3=1 /\ 2:r4=1 /\ 2:r1=0 /\ 3:r2=0)
> > > 
> > > 
> > > Is what I was thinking of, I think that is the minimal ordering
> > > complete()/wait_for_completion() need to provide.
> > 
> > OK, I will bite...  What do the smp_store_release() and the
> > smp_load_acquire() correspond to?  I see just plain locking in
> > wait_for_completion() and complete().
> 
> They reflect the concept of complete() / wait_for_completion().
> Fundamentally all it needs to do is pass the message of 'completion'.
> 
> That is, if we were to go optimize our completion implementation, it
> would be impossible to be weaker than this and still correct.

OK, though the model does not provide spinlocks, and there can be
differences in behavior between spinlocks and release-acquire.
But yes, in this case, it works.

> > So I dropped that patch yesterday.  The main thing I was missing was
> > that there is no ordering-free fastpath in wait_for_completion() and
> > complete(): Each unconditionally acquires the lock.  So the smp_mb()
> > that I was trying to add doesn't need to be there.
> 
> Going by the above, it never needs to be there, even if there was a
> lock-free fast-path.

Given that wait_for_completion()/complete() both acquire the same lock,
yes, and agreed, if it were lockless but provided the release and
acquire ordering, then yes.  But if it was instead structured like
wait_event()/wake_up(), there would be ordering only if the caller
supplied it.

All that aside, paring the ordering down to the bare minimum is not
always the right approach.  Nevertheless, in this particular case,
there is plenty of ordering, so yet again, I have dropped this commit.
Like yesterday.  ;-)

							Thanx, Paul