Re: Is it ok for deferrable timer wakeup the idle cpu?

[Frederic Weisbecker <fweisbec@gmail.com>]

On Thu, Jan 23, 2014 at 11:22:32AM +0530, Viresh Kumar wrote:
> I think below diff might get this fixed for you, though I am not sure if it
> breaks something else. Probably Thomas/Frederic can answer here.
> If this looks fine I will send it formally again:
> 
> diff --git a/kernel/timer.c b/kernel/timer.c
> index accfd24..3a2c7fa 100644
> --- a/kernel/timer.c
> +++ b/kernel/timer.c
> @@ -940,7 +940,8 @@ void add_timer_on(struct timer_list *timer, int cpu)
>          * makes sure that a CPU on the way to stop its tick can not
>          * evaluate the timer wheel.
>          */
> -       wake_up_nohz_cpu(cpu);
> +       if (!tbase_get_deferrable(timer->base))
> +               wake_up_nohz_cpu(cpu);

So you simply rely on the next tick to see the new timer. This should work with
CONFIG_NO_HZ_IDLE but not with CONFIG_NO_HZ_FULL since the target may be running
without the tick.

Basically, in the case of a deferrable timer you need to manage to call
wake_up_full_nohz_cpu() but not wake_up_idle_cpu().

It should be even possible to spare the IPI in a full dynticks CPU if it is
running idle. But that's an optional bonus because it require some deep
care on complicated races against the call to tick_nohz_idle_exit().

I also realize than when we enqueue a timer on a full nohz CPU, we should set_need_resched()
the target before sending the IPI if it is idle like does wake_up_idle_cpu(). Otherwise the
IPI will be ignored without exiting the idle loop nor reevaluating the tick on irq exit.
If you can fix that along the way, that will be much appreciated.

Thanks!