From: "Doug Smythies" <dsmythies@telus.net>
To: "'Rafael J. Wysocki'" <rafael@kernel.org>,
"'Christian Loehle'" <christian.loehle@arm.com>
Cc: "'LKML'" <linux-kernel@vger.kernel.org>,
"Doug Smythies" <dsmythies@telus.net>,
"'Linux PM'" <linux-pm@vger.kernel.org>
Subject: RE: [Update][PATCH v1.1 4/5] cpuidle: governors: teo: Adjust the classification of wakeup events
Date: Sun, 25 Jan 2026 09:21:00 -0800 [thread overview]
Message-ID: <004301dc8e1e$fa328450$ee978cf0$@telus.net> (raw)
In-Reply-To: <4707705.LvFx2qVVIh@rafael.j.wysocki>
[-- Attachment #1: Type: text/plain, Size: 3092 bytes --]
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
[-- Attachment #2: misses.png --]
[-- Type: image/png, Size: 59639 bytes --]
next prev parent reply other threads:[~2026-01-25 17:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 19:42 [PATCH v1 0/5] cpuidle: governors: teo: Wakeup events classification change and some refinements Rafael J. Wysocki
2026-01-14 19:44 ` [PATCH v1 1/5] cpuidle: governors: teo: Avoid selecting states with zero-size bins Rafael J. Wysocki
2026-01-21 13:09 ` Christian Loehle
2026-01-23 20:46 ` Rafael J. Wysocki
2026-01-26 9:18 ` Christian Loehle
2026-01-26 11:40 ` Rafael J. Wysocki
2026-01-26 12:05 ` Christian Loehle
2026-01-14 19:44 ` [PATCH v1 2/5] cpuidle: governors: teo: Avoid fake intercepts produced by tick Rafael J. Wysocki
2026-01-21 13:34 ` Christian Loehle
2026-01-14 19:45 ` [PATCH v1 3/5] cpuidle: governors: teo: Refine tick_intercepts vs total events check Rafael J. Wysocki
2026-01-21 13:36 ` Christian Loehle
2026-01-14 19:46 ` [PATCH v1 4/5] cpuidle: governors: teo: Adjust the classification of wakeup events Rafael J. Wysocki
2026-01-14 19:47 ` [PATCH v1 5/5] cpuidle: governors: teo: Refine intercepts-based idle state lookup Rafael J. Wysocki
2026-01-16 11:52 ` [PATCH v1 0/5] cpuidle: governors: teo: Wakeup events classification change and some refinements Christian Loehle
2026-01-16 12:29 ` Rafael J. Wysocki
2026-01-19 9:53 ` Christian Loehle
2026-01-19 12:09 ` Rafael J. Wysocki
2026-01-19 16:20 ` Doug Smythies
2026-01-20 15:29 ` [Update][PATCH v1.1 4/5] cpuidle: governors: teo: Adjust the classification of wakeup events Rafael J. Wysocki
2026-01-25 17:21 ` Doug Smythies [this message]
2026-01-25 19:38 ` Christian Loehle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='004301dc8e1e$fa328450$ee978cf0$@telus.net' \
--to=dsmythies@telus.net \
--cc=christian.loehle@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.