[Update][PATCH v1.1 4/5] cpuidle: governors: teo: Adjust the classification of wakeup events

Posted by Rafael J. Wysocki 2 weeks, 4 days ago

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

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 difference
between the sleep length and the measured idle duration is less than
LATENCY_THRESHOLD_NS (which means that the difference between the
sleep length and the raw measured idle duration is below the sum of
LATENCY_THRESHOLD_NS and 1/2 of the entered idle state exit latency).
Otherwise, the event will be counted as an intercept.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

v1 -> v1.1
   * Drop the change in teo_select() along with the corresponding
     part of the changelog (after receiving testing feedback from
     Christian)

---
 drivers/cpuidle/governors/teo.c |   32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

--- a/drivers/cpuidle/governors/teo.c
+++ b/drivers/cpuidle/governors/teo.c
@@ -48,13 +48,11 @@
  * in accordance with what happened last time.
  *
  * The "hits" metric reflects the relative frequency of situations in which the
- * sleep length and the idle duration measured after CPU wakeup fall into the
- * same bin (that is, the CPU appears to wake up "on time" relative to the sleep
- * length).  In turn, the "intercepts" metric reflects the relative frequency of
- * non-timer wakeup events for which the measured idle duration falls into a bin
- * that corresponds to an idle state shallower than the one whose bin is fallen
- * into by the sleep length (these events are also referred to as "intercepts"
- * below).
+ * sleep length and the idle duration measured after CPU wakeup are close enough
+ * (that is, the CPU appears to wake up "on time" relative to the sleep length).
+ * In turn, the "intercepts" metric reflects the relative frequency of non-timer
+ * wakeup events for which the measured idle duration is measurably less than
+ * the sleep length (these events are also referred to as "intercepts" below).
  *
  * The governor also counts "intercepts" with the measured idle duration below
  * the tick period length and uses this information when deciding whether or not
@@ -253,12 +251,16 @@ static void teo_update(struct cpuidle_dr
 	}
 
 	/*
-	 * If the measured idle duration falls into the same bin as the sleep
-	 * length, this is a "hit", so update the "hits" metric for that bin.
+	 * If the measured idle duration falls into the same bin as the
+	 * sleep length and the difference between them is less than
+	 * LATENCY_THRESHOLD_NS, this is a "hit", so update the "hits"
+	 * metric for that bin.
+	 *
 	 * Otherwise, update the "intercepts" metric for the bin fallen into by
 	 * the measured idle duration.
 	 */
-	if (idx_timer == idx_duration) {
+	if (idx_timer == idx_duration &&
+	    cpu_data->sleep_length_ns - measured_ns < LATENCY_THRESHOLD_NS) {
 		cpu_data->state_bins[idx_timer].hits += PULSE;
 	} else {
 		cpu_data->state_bins[idx_duration].intercepts += PULSE;

RE: [Update][PATCH v1.1 4/5] cpuidle: governors: teo: Adjust the classification of wakeup events

Posted by Doug Smythies 1 week, 5 days ago

On 2026.01.20 07:30 Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> 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 difference
> between the sleep length and the measured idle duration is less than
> LATENCY_THRESHOLD_NS (which means that the difference between the
> sleep length and the raw measured idle duration is below the sum of
> LATENCY_THRESHOLD_NS and 1/2 of the entered idle state exit latency).
> Otherwise, the event will be counted as an intercept.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>
> v1 -> v1.1
>   * Drop the change in teo_select() along with the corresponding
>     part of the changelog (after receiving testing feedback from
>     Christian)

With this updated patch I have not observed any difference in testing
results or power consumption between kernels without or with the
5 patch set:

c66de7fc0157 (HEAD -> rjw-1-1) cpuidle: governors: teo: Adjust the classification of wakeup events
25f70be81668 Revert "cpuidle: governors: teo: Adjust the classification of wakeup events"
f0ae302c4635 cpuidle: governors: teo: Refine intercepts-based idle state lookup
f5ad355214de cpuidle: governors: teo: Adjust the classification of wakeup events
1c5b66c336ea cpuidle: governors: teo: Refine tick_intercepts vs total events check
36148eea2ec2 cpuidle: governors: teo: Avoid fake intercepts produced by tick
8b1ad7bc8a7f cpuidle: governors: teo: Avoid selecting states with zero-size bins
0f61b1860cc3 (tag: v6.19-rc5, origin/master, origin/HEAD, master) Linux 6.19-rc5

My test system:
Processor: Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz, 6 cores 12 CPUs.
HWP: Enabled.
state0/name:POLL
state1/name:C1_ACPI
state2/name:C2_ACPI
state3/name:C3_ACPI

@Christian: I noticed that you like "idle misses" in test results. I have added
percent "idle misses" to my test results. An example graph is attached.

Legend:
rc5 = kernel 6.19-rc5
rjw = kernel 6.19-rc5 + original 5 patch set
rjw-1-1 = kernel 6.19-rc5 + current 5 patch set

See also my previous email [1] about the original 5 patch set:

[1] https://lore.kernel.org/linux-pm/003201dc895f$8cfb2540$a6f16fc0$@telus.net/

... Doug

Re: [Update][PATCH v1.1 4/5] cpuidle: governors: teo: Adjust the classification of wakeup events

Posted by Christian Loehle 1 week, 5 days ago

On 1/25/26 17:21, Doug Smythies wrote:
> On 2026.01.20 07:30 Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>> 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 difference
>> between the sleep length and the measured idle duration is less than
>> LATENCY_THRESHOLD_NS (which means that the difference between the
>> sleep length and the raw measured idle duration is below the sum of
>> LATENCY_THRESHOLD_NS and 1/2 of the entered idle state exit latency).
>> Otherwise, the event will be counted as an intercept.
>>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> ---
>>
>> v1 -> v1.1
>>   * Drop the change in teo_select() along with the corresponding
>>     part of the changelog (after receiving testing feedback from
>>     Christian)
> 
> With this updated patch I have not observed any difference in testing
> results or power consumption between kernels without or with the
> 5 patch set:
> 
> c66de7fc0157 (HEAD -> rjw-1-1) cpuidle: governors: teo: Adjust the classification of wakeup events
> 25f70be81668 Revert "cpuidle: governors: teo: Adjust the classification of wakeup events"
> f0ae302c4635 cpuidle: governors: teo: Refine intercepts-based idle state lookup
> f5ad355214de cpuidle: governors: teo: Adjust the classification of wakeup events
> 1c5b66c336ea cpuidle: governors: teo: Refine tick_intercepts vs total events check
> 36148eea2ec2 cpuidle: governors: teo: Avoid fake intercepts produced by tick
> 8b1ad7bc8a7f cpuidle: governors: teo: Avoid selecting states with zero-size bins
> 0f61b1860cc3 (tag: v6.19-rc5, origin/master, origin/HEAD, master) Linux 6.19-rc5
> 
> My test system:
> Processor: Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz, 6 cores 12 CPUs.
> HWP: Enabled.
> state0/name:POLL
> state1/name:C1_ACPI
> state2/name:C2_ACPI
> state3/name:C3_ACPI
> 
> @Christian: I noticed that you like "idle misses" in test results. I have added
> percent "idle misses" to my test results. An example graph is attached.

Thanks for the test!
So rjw-1-1 looks pretty much the same on rc5 as well, that's good.
I guess since the v1 of 4/5 change that did have an affect was added by Rafael
to mitigate the more liberal intercept counting, that should be fine then.
Interestingly here (in overall idle_misses) rjw (with 4/5 v1) has significantly
fewer idle_misses, while in state2 aboves it was much worse as per your previous
test results.

> 
> Legend:
> rc5 = kernel 6.19-rc5
> rjw = kernel 6.19-rc5 + original 5 patch set
> rjw-1-1 = kernel 6.19-rc5 + current 5 patch set
> 
> See also my previous email [1] about the original 5 patch set:
> 
> [1] https://lore.kernel.org/linux-pm/003201dc895f$8cfb2540$a6f16fc0$@telus.net/
> 
> ... Doug
>