Re: [patch V4 part 1 03/36] sched: Clean up scheduler_ipi()

Paul E. McKenney
2020-05-06T18:28:58Z

On Wed, May 06, 2020 at 05:33:00PM +0200, Peter Zijlstra wrote:
> On Wed, May 06, 2020 at 02:37:19PM +0200, Alexandre Chartre wrote:
> > On 5/5/20 3:16 PM, Thomas Gleixner wrote:
> > > @@ -650,6 +655,16 @@ static inline bool got_nohz_idle_kick(vo
> > > return false;
> > > }
> > > +static void nohz_csd_func(void *info)
> > > +{
> > > + struct rq *rq = info;
> > > +
> > > + if (got_nohz_idle_kick()) {
> > > + rq->idle_balance = 1;
> > > + raise_softirq_irqoff(SCHED_SOFTIRQ);
> > > + }
> > > +}
> > > +
> > > #else /* CONFIG_NO_HZ_COMMON */
> > > static inline bool got_nohz_idle_kick(void)
>
> > > #ifdef CONFIG_NO_HZ_COMMON
> > > rq->last_blocked_load_update_tick = jiffies;
> > > atomic_set(&rq->nohz_flags, 0);
> > > +
> > > + rq_csd_init(rq, &rq->nohz_csd, nohz_csd_func);
> > > #endif
> > > #endif /* CONFIG_SMP */
> > > hrtick_rq_init(rq);
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -10009,12 +10009,11 @@ static void kick_ilb(unsigned int flags)
> > > return;
> > > /*
> > > - * Use smp_send_reschedule() instead of resched_cpu().
> > > - * This way we generate a sched IPI on the target CPU which
> > > + * This way we generate an IPI on the target CPU which
> > > * is idle. And the softirq performing nohz idle load balance
> > > * will be run before returning from the IPI.
> > > */
> > > - smp_send_reschedule(ilb_cpu);
> > > + smp_call_function_single_async(ilb_cpu, &cpu_rq(ilb_cpu)->wake_csd);
> >
> > This should be nohz_csd instead of wake_csd, no? I.e.:
> >
> > smp_call_function_single_async(ilb_cpu, &cpu_rq(ilb_cpu)->nohz_csd);
>
> You figured correctly. Thanks!

And this does get rid of the smp_call_function splats I was seeing
earlier, thank you!

I still see warnings of the form "leave instruction with modified stack
frame" from older complilers and of the form "undefined stack state"
from newer compilers. I am running stock objtool versions, so I am
guessing that this is at least one reason for these warnings.

Thanx, Paul