Re: [patch 1/2] tick/broadcast: Prevent deep idle states if no broadcast device available

From: Sudeep Holla
Date: Mon Jul 06 2015 - 11:44:35 EST




On 06/07/15 16:35, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Sudeep Holla wrote:
On 05/07/15 21:53, Thomas Gleixner wrote:
If no broadcast device is installed and the cpu local timers stop in
deeper idle states, then there is currently nothing telling the idle
code that it should not go into deep idle states, so the timers stop
and nothing wakes up the cpus.

Make the broadcast_enter/exit() functions independent of the
configuration options and always check on enter:

- whether the cpu local device is affected by idle states
- whether a broadcast device is available

This covers all possible config combinations including
CONFIG_BROADCAST=n.

Reported-by: Sudeep Holla <sudeep.holla@xxxxxxx>

Sorry for the delay, took a while testing few configuration:

+--------------+--------+--------------+--------------------+
| Configs | PERIOD | HRTimers+NOHz|Cmdline(HR+NoHZ=off)|
+--------------+--------+--------------+--------------------+
| UP w/o H/W BC| OK | OK | OK |
+--------------+--------+--------------+--------------------+
| UP w/ H/W BC | OK | OK | OK |
+--------------+--------+--------------+--------------------+
|SMP w/o H/W BC| OK* | OK | Not OK(**) |
+--------------+--------+--------------+--------------------+
|SMP w/ H/W BC | OK | OK | OK |
+--------------+--------+--------------+--------------------+

H/W BC - Hardware Broadcast Timer source

(*) None of the CPUs enters deeper idle states losing local timers

(**)SMP build without Hardware Broadcast Timer source(i.e. one cpu is
the broadcast source) with HRTimers+NOHz configs but disabled in cmdline
fails to boot.

That's using the hrtimer broadcast mechanism, right?


Correct.

On connecting debugger, I found all the cpus are in
shallow idle state(i.e. WFI in ARM) but with interrupts disabled.

And that means?


All CPUs have entered WFI with interrupts disabled and no way to wake them up.

I am not really keen on the failing configuration. We have never tested
that before, though I found it working with CPUIdle disabled.

Well, we should figure out what happens while we are at it before
everything gets paged out again.


True. I just wanted to mention that this patch works for all the
practical purposes.

In the case of CONFIG_NOHZ=n and CONFIG_HIGHRES=n the broadcast
hrtimer is not compiled as it depends on CONFIG_TICK_ONESHOT, so it
works via the bc.evtdev == NULL check.

With either option enabled CONFIG_TICK_ONESHOT gets set, so the
broadcast timer gets installed but somehow does not work proper if
nohz and highres are disabled on the kernel command line.


Let me know if you want to test something to help debug this configuration.

Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/