Re: [PATCH 0/6] sched: TTWU, IPI, and assorted stuff

[Paul E. McKenney]

On Fri, Jun 19, 2020 at 08:11:28PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 19, 2020 at 10:48:02AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 19, 2020 at 10:20:47AM -0700, Paul E. McKenney wrote:
> 
> > > > @@ -2615,7 +2617,8 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
> > > >  	 * let the waker make forward progress. This is safe because IRQs are
> > > >  	 * disabled and the IPI will deliver after on_cpu is cleared.
> > > >  	 */
> > > > -	if (READ_ONCE(p->on_cpu) && ttwu_queue_wakelist(p, cpu, wake_flags | WF_ON_RQ))
> > > > +	if (smp_load_acquire(&p->on_cpu) &&
> > 
> > Given the x86 memory model, this only protects against the compiler
> > reordering accesses in ttwu_queue_wakelist() against the fetch of
> > p->on_cpu, correct?
> 
> Yes.
> 
> > Don't get me wrong, I do see some potential compiler misorderings,
> > including with cpu_rq(cpu)->nr_running.  Just curious.
> 
> Given this is arch independent code, I'd better write generic code, and
> there I really think this wants to be acquire. I'll also try and write a
> comment for next time.

I completely understand and agree.  Just trying to work out why my
systems hit this more than an order of magnitude more often than do
yours.  Compiler version might be important?  As noted on IRC, I am
using gcc 8.2.1.

							Thanx, Paul