[PATCH v2 0/2] cpuidle: governor: Modify the handling of stopped tick

["Rafael J. Wysocki" <rafael@kernel.org>]

Hi All,

This is an update of

https://lore.kernel.org/linux-pm/1953482.tdWV9SEqCh@rafael.j.wysocki/

that fixes an issue in the second patch.  The first patch does not change and
the changelog below still applies.

When I was thinking about possible ways to address high CPU wakeup latency on
isolated CPUs resulting from the selection of deep idle states by cpuidle
governors, it occurred to me that it is not always necessary to select a
deep idle state if the scheduler tick has been stopped.  Namely, if a timer
is going to trigger (relatively) shortly, a shallow state may as well be
selected because the timer will kick the CPU out of that state anyway and
getting stuck in it for a long time is not a concern.

Changing the menu governor to take that observation into account is a 2-line
patch, modulo a comment update (patch [1/2]).  Of course, the SAFE_TIMER_RANGE_NS
value is somewhat arbitrary.

Updating the teo governor accordingly is a bit more challenging, but overall it
is a major simplification of the stopped tick handling there, so IMV it is very
much worth doing (patch [2/2]).

By itself, this is not going to help workloads running on isolated CPUs too
much, but if SAFE_TIMER_RANGE_NS were replaced with a per-CPU tunable, that
could help people to configure their systems to avoid the latency issue
mentioned above.

Thanks,
Rafael