kernel/git/next/linux-next.git/drivers/cpuidle/governors, branch master

cpuidle: teo: Do not return a disabled idle state

2026-09-11T14:23:52+00:00

If idle state 0 is disabled and none of the enabled idle states satisfies the PM QoS latency constraint, constraint_idx in teo_select() stays at its initial value of 0, because the loop that updates it starts at state 1, and so the candidate state index is capped at state 0, which is disabled, and that state is returned to the caller. The cpuidle core does not validate the returned state index against the per-state disable flags, so the CPU ends up entering the disabled state 0. To address this, ensure that constraint_idx is at least equal to the index of the first enabled idle state (idx0), so that the candidate state is never capped to a disabled one. Fixes: c410a9a142f1 ("cpuidle: teo: Change the main idle state selection logic") Signed-off-by: Xueqin Luo Reviewed-by: Christian Loehle Link: https://patch.msgid.link/20260828032457.2317326-1-luoxueqin@kylinos.cn Signed-off-by: Rafael J. Wysocki

cpuidle: menu: Do not return a disabled idle state

2026-09-11T14:20:00+00:00

When idle state 0 is disabled and the PM QoS latency constraint is zero (latency_req == 0), the first branch of the || in the early-return condition of menu_select() is taken immediately, so state 0 is returned regardless of its disable flag. Address this by making the !disable check a prerequisite for the entire early-return condition, so that when state 0 is disabled the normal state selection loop is used instead, which already skips disabled states. Fixes: 53812cdc9100 ("cpuidle: menu: Move the latency_req == 0 special case check") Signed-off-by: Xueqin Luo Link: https://patch.msgid.link/20260827094820.3900062-1-luoxueqin@kylinos.cn Signed-off-by: Rafael J. Wysocki

cpuidle: governors: teo: Rearrange stopped tick handling

2026-03-05T14:23:16+00:00

This change is based on the observation that it is not in fact necessary to select a deep idle state every time the scheduler tick has been stopped before the idle state selection takes place. Namely, if the time till the closest timer (that is not the tick) is short enough, a shallow idle state can be selected because the timer will kick the CPU out of that state, so the damage from a possible overly optimistic selection will be limited. Update the teo governor in accordance with the above in analogy with the previous analogous menu governor update. Among other things, this will cause the teo governor to call tick_nohz_get_sleep_length() every time when the tick has been stopped already and only change the original idle state selection if the time till the closest timer is beyond SAFE_TIMER_RANGE_NS which is way more straightforward than the current code flow. Of course, this effectively throws away some of the recent teo governor changes made recently, but the resulting simplification is worth it in my view. Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle Link: https://patch.msgid.link/1865078.VLH7GnMWUR@rafael.j.wysocki

cpuidle: governors: menu: Refine stopped tick handling

2026-03-05T14:23:16+00:00

cpuidle: menu: Remove single state handling

2026-02-17T14:49:53+00:00

cpuidle systems where the governor has no choice because there's only a single idle state are now handled by cpuidle core and bypass the governor, so remove the related handling. Signed-off-by: Christian Loehle [ rjw: Rebase on top of the cpuidle changes merged recently ] Link: https://patch.msgid.link/20260216185005.1131593-5-aboorvad@linux.ibm.com Signed-off-by: Rafael J. Wysocki

cpuidle: teo: Remove single state handling

2026-02-17T14:49:53+00:00

cpuidle systems where the governor has no choice because there's only a single idle state are now handled by cpuidle core and bypass the governor, so remove the related handling. Signed-off-by: Christian Loehle Link: https://patch.msgid.link/20260216185005.1131593-4-aboorvad@linux.ibm.com Signed-off-by: Rafael J. Wysocki

cpuidle: haltpoll: Remove single state handling

2026-02-17T14:49:24+00:00

cpuidle systems where the governor has no choice because there's only a single idle state are now handled by cpuidle core and bypass the governor, so remove the related handling. Signed-off-by: Aboorva Devarajan Reviewed-by: Christian Loehle [ rjw: Extended the change to drop a redundant local variable ] Link: https://patch.msgid.link/20260216185005.1131593-3-aboorvad@linux.ibm.com Signed-off-by: Rafael J. Wysocki

cpuidle: governors: teo: Refine intercepts-based idle state lookup

2026-01-30T19:15:52+00:00

There are cases in which decisions made by the teo governor are arguably overly conservative. For instance, suppose that there are 4 idle states and the values of the intercepts metric for the first 3 of them are 400, 250, and 251, respectively. If the total sum computed in teo_update() is 1000, the governor will select idle state 1 (provided that all idle states are enabled and the scheduler tick has not been stopped) although arguably idle state 0 would be a better choice because the likelihood of getting an idle duration below the target residency of idle state 1 is greater than the likelihood of getting an idle duration between the target residency of idle state 1 and the target residency of idle state 2. To address this, refine the candidate idle state lookup based on intercepts to start at the state with the maximum intercepts metric, below the deepest enabled one, to avoid the cases in which the search may stop before reaching that state. Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle [ rjw: Fixed typo "intercetps" in new comments (3 places) ] Link: https://patch.msgid.link/2417298.ElGaqSPkdT@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki

cpuidle: governors: teo: Adjust the classification of wakeup events

2026-01-30T19:15:43+00:00

If differences between target residency values of adjacent idle states of a given CPU are relatively large, the corresponding idle state bins used by the teo governors are large either and the rule by which hits are distinguished from intercepts is inaccurate. Namely, by that rule, a wakeup event is classified as a hit if the sleep length (the time till the closest timer other than the tick) and the measured idle duration, adjusted for the entered idle state exit latency, fall into the same idle state bin. However, if that bin is large enough, the actual difference between the sleep length and the measured idle duration may be significant. It may in fact be significantly greater than the analogous difference for an event where the sleep length and the measured idle duration fall into different bins. For this reason, amend the rule in question with a check that will only allow a wakeup event to be counted as a hit if the sleep length is less than the "raw" measured idle duration (which means that the wakeup appears to have occurred after the anticipated timer event). Otherwise, the event will be counted as an intercept. Also update the documentation part explaining the difference between "hits" and "intercepts" to take the above change into account. Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle Link: https://patch.msgid.link/5093379.31r3eYUQgx@rafael.j.wysocki

cpuidle: governors: teo: Refine tick_intercepts vs total events check

2026-01-23T20:50:38+00:00

Use 2/3 as the proportion coefficient in the check comparing cpu_data->tick_intercepts with cpu_data->total because it is close enough to the current one (5/8) and it allows of more straightforward interpretation (on average, intercepts within the tick period length are twice as frequent as other events). Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle Link: https://patch.msgid.link/10793374.nUPlyArG6x@rafael.j.wysocki