diff options
author | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2019-07-19 12:12:42 +0200 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2019-08-05 11:02:44 +0200 |
commit | cab09f3d2d2a0a6cb3dfb678660d67a2c3764f50 (patch) | |
tree | 36ee7c7461b5c4d502248ebe7820417a752bd3a1 /arch/ia64 | |
parent | cpuidle: menu: Allow tick to be stopped if PM QoS is used (diff) | |
download | linux-cab09f3d2d2a0a6cb3dfb678660d67a2c3764f50.tar.xz linux-cab09f3d2d2a0a6cb3dfb678660d67a2c3764f50.zip |
cpuidle: teo: Allow tick to be stopped if PM QoS is used
The TEO goveror prevents the scheduler tick from being stopped (unless
stopped already) if there is a PM QoS latency constraint for the given
CPU and the target residency of the deepest idle state matching that
constraint is below the tick boundary.
However, that is problematic if CPUs with PM QoS latency constraints
are idle for long times, because it effectively causes the tick to
run on them all the time which is wasteful. [It is also confusing
and questionable if they are full dynticks CPUs.]
To address that issue, modify the TEO governor to carry out the
entire search for the most suitable idle state (from the target
residency perspective) even if a latency constraint is present,
to allow it to determine the expected idle duration in all cases.
Also, when using the last several measured idle duration values
to refine the idle state selection, make it compare those values
with the current expected idle duration value (instead of
comparing them with the target residency of the idle state
selected so far) which should prevent the tick from being
retained when it makes sense to stop it sometimes (especially
in the presence of PM QoS latency constraints).
Fixes: b26bf6ab716f ("cpuidle: New timer events oriented governor for tickless systems")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'arch/ia64')
0 files changed, 0 insertions, 0 deletions