summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2018-10-10 14:16:38 +0200
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2018-10-12 10:46:37 +0200
commitbde091ece2ad3f78d0896870f041bc52761ea3c1 (patch)
tree51d8f62ea6d9e00aa1064c3ecf1c80c213b27618
parentcpuidle: poll_state: Revise loop termination condition (diff)
downloadlinux-bde091ece2ad3f78d0896870f041bc52761ea3c1.tar.xz
linux-bde091ece2ad3f78d0896870f041bc52761ea3c1.zip
cpuidle: menu: Simplify checks related to the polling state
After some recent menu governor changes, the promotion of the "polling" state to a physical one is mostly controlled by the latency limit (resulting from the "interactivity" factor) and not by the time to the closest timer event, so it should be sufficient to check the exit latency of that state for this purpose (of course, its target residency still needs to be within the next timer event range for energy-efficiency). Also, the physical state the "polling" one is promoted to need not be the next one in principle (in case the next state is disabled, for example). For these reasons, simplify the checks made to decide whether or not to promote the "polling" state to a physical one and update the target idle duration when it is promoted in case the residency of the new state turns out to be above the tick boundary (in which case there is no reason to stop the tick). Tested-by: Doug Smythies <dsmythies@telus.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-rw-r--r--drivers/cpuidle/governors/menu.c8
1 files changed, 4 insertions, 4 deletions
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index b754296eb0c5..4ed8004643f8 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -371,12 +371,12 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
if (s->target_residency > predicted_us) {
/*
* Use a physical idle state, not busy polling, unless
- * a timer is going to trigger really really soon.
+ * a timer is going to trigger soon enough.
*/
if ((drv->states[idx].flags & CPUIDLE_FLAG_POLLING) &&
- i == idx + 1 && latency_req > s->exit_latency &&
- data->next_timer_us > max_t(unsigned int, 20,
- s->target_residency)) {
+ s->exit_latency <= latency_req &&
+ s->target_residency <= data->next_timer_us) {
+ predicted_us = s->target_residency;
idx = i;
break;
}