Commit bde091ece2ad3f78d0896870f041bc52761ea3c1

Authored by Rafael J. Wysocki
1 parent 01bad1c689

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>

Showing 1 changed file with 4 additions and 4 deletions Side-by-side Diff

drivers/cpuidle/governors/menu.c
... ... @@ -371,12 +371,12 @@
371 371 if (s->target_residency > predicted_us) {
372 372 /*
373 373 * Use a physical idle state, not busy polling, unless
374   - * a timer is going to trigger really really soon.
  374 + * a timer is going to trigger soon enough.
375 375 */
376 376 if ((drv->states[idx].flags & CPUIDLE_FLAG_POLLING) &&
377   - i == idx + 1 && latency_req > s->exit_latency &&
378   - data->next_timer_us > max_t(unsigned int, 20,
379   - s->target_residency)) {
  377 + s->exit_latency <= latency_req &&
  378 + s->target_residency <= data->next_timer_us) {
  379 + predicted_us = s->target_residency;
380 380 idx = i;
381 381 break;
382 382 }