lkml.org 
[lkml]   [2019]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] timers/nohz: Update nohz load even if tick already stopped
From
Date
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

\
 
 \ /
  Last update: 2019-12-11 21:46    [W:0.093 / U:0.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site