On Wed, Jun 04, 2014 at 05:11:08PM +0530, Viresh Kumar wrote:

Hi,

While working on the ONESHOT_STOPPED mode I came across another confusing scenario..

Normal timers (kernel/timer.c) don't configure clockevent devices at all but they always rely on PERIODIC tick interrupts to get them scheduled. i.e. normal timers would be only serviced at next tick interrupt (in both LOW & HIGH resolution modes)..

Suppose we have entered into NO_HZ_FULL mode (we made sure that there are no normal timers queued) and a normal timer was added after that. We will add it to the timer list but as there is no tick-sched timer, we wouldn't be able to service the normal timer until next time tick fires again (MAX 1 second currently)..

And once we remove this MAX 1 second limitation, we might not service this normal timer for long..

Does this problem statement make sense? Or we don't have any such problem?

Right, if we enqueue a timer when the tick is stopped, we call wake_up_nohz_cpu(). So here is two scenarios:

1) Target is remote. An IPI is sent if necessary and the next tick is reevaluated from the target's irq exit

2) Target is local. We assume that nobody needs to enqueue a timer between tick_nohz_idle_enter() and tick_nohz_idle_exit() calls. Because it's dead idle area. But irqs can happen in nohz mode, and they can queue timers. Then the next tick can be reevaluated on irq exit. But we should better check that no code like idle drivers, governors and other idle stuff ever call a timer on the dead zone.

Now full nohz is actually special in that it can call the ipi locally if the target is local. This is currently using the scheduler IPI but I may change that to use irq work because I'm not sure that all archs support scheduler self-IPIs.