Messages in this thread | | | Subject | Re: [PATCH] timers/nohz: Update nohz load even if tick already stopped | From | Scott Wood <> | Date | Wed, 11 Dec 2019 14:46:01 -0600 |
| |
On Wed, 2019-10-30 at 14:31 +0100, Peter Zijlstra wrote: > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index eb42b71faab9..d02d1b8f40af 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -3660,21 +3660,17 @@ static void sched_tick_remote(struct work_struct > *work) > u64 delta; > int os; > > - /* > - * Handle the tick only if it appears the remote CPU is running in > full > - * dynticks mode. The check is racy by nature, but missing a tick or > - * having one too much is no big deal because the scheduler tick > updates > - * statistics and checks timeslices in a time-independent way, > regardless > - * of when exactly it is running. > - */ > - if (idle_cpu(cpu) || !tick_nohz_tick_stopped_cpu(cpu)) > + if (!tick_nohz_tick_stopped_cpu(cpu)) > goto out_requeue; > > rq_lock_irq(rq, &rf); > - curr = rq->curr; > - if (is_idle_task(curr) || cpu_is_offline(cpu)) > + /* > + * We must not call calc_load_nohz_remote() when not in NOHZ mode. > + */ > + if (cpu_is_offline(cpu) || !tick_nohz_tick_stopped(cpu)) > goto out_unlock;
Is it really a problem if calc_load_nohz_remote() gets called in non-NOHZ? It won't race due to rq lock -- and we're already mixing remote and non-remote updates because the normal tick timer can still be run while "stopped".
-Scott
| |