linux-kernel - Re: [Query] Can we use normal timers (kernel/timer.c) while in NO_HZ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 4 Jun 2014 15:23:07 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Kevin Hilman <khilman@...aro.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linaro Networking <linaro-networking@...aro.org>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>
Subject: Re: [Query] Can we use normal timers (kernel/timer.c) while in
 NO_HZ_FULL mode?

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/