Re: [PATCH 2/3] task: RCU protect tasks on the runqueue

[Paul E. McKenney]

On Tue, Sep 03, 2019 at 10:06:03PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 03, 2019 at 12:18:47PM -0700, Linus Torvalds wrote:
> > Now, if you can point to some particular field where that ordering
> > makes sense for the particular case of "make it active on the
> > runqueue" vs "look up the task from the runqueue using RCU", then I do
> > think that the whole release->acquire consistency makes sense.
> > 
> > But it's not clear that such a field exists, particularly when this is
> > in no way the *common* way to even get a task pointer, and other paths
> > do *not* use the runqueue as the serialization point.
> 
> Even if we could find a case (and I'm not seeing one in a hurry), I
> would try really hard to avoid adding extra barriers here and instead
> make the consumer a little more complicated if at all possible.
> 
> The Power folks got rid of a SYNC (yes, more expensive than LWSYNC) from
> their __switch_to() implementation and that had a measurable impact.
> 
> 9145effd626d ("powerpc/64: Drop explicit hwsync in context switch")

The patch [1] looks good to me.  And yes, if the structure pointed to by
the second argument of rcu_assign_pointer() is already visible to readers,
it is OK to instead use RCU_INIT_POINTER().  Yes, this loses ordering.
But weren't these simple assignments before RCU got involved?

As a very rough rule of thumb, LWSYNC is about twice as fast as SYNC.
(Depends on workload, exact details of the hardware, timing, phase of
the moon, you name it.)  So removing the LWSYNC is likely to provide
measureable benefit, but I must defer to the powerpc maintainers.
To that end, I added Michael on CC.

							Thanx, Paul

[1] https://lore.kernel.org/lkml/878sr6t21a.fsf_-_@xxxxxxxxxxxxxxxxxxxxx/