linux-kernel - RE: [PATCH v1 0/2] cpuidle: governors: teo: Fix and simplification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <003e01dc63b4$afd50a70$0f7f1f50$@telus.net>
Date: Tue, 2 Dec 2025 09:54:20 -0800
From: "Doug Smythies" <dsmythies@...us.net>
To: "'Christian Loehle'" <christian.loehle@....com>,
	"'Rafael J. Wysocki'" <rafael@...nel.org>
Cc: "'LKML'" <linux-kernel@...r.kernel.org>,
	"'Linux PM'" <linux-pm@...r.kernel.org>,
	"Doug Smythies" <dsmythies@...us.net>
Subject: RE: [PATCH v1 0/2] cpuidle: governors: teo: Fix and simplification

On 2025.11.29 15:46 Christian Loehle wrote:
> On 11/16/25 12:31, Rafael J. Wysocki wrote:
>> Hi,
>> 
>> This series is based on
>> 
>> https://lore.kernel.org/linux-pm/6228387.lOV4Wx5bFT@rafael.j.wysocki/
>> 
>> and the previous teo updates sent recently.
>> 
>> It fixes a reverse condition in teo_update() (first patch) and quite
>> dramatically simplifies the "intercepts" logic in teo_select() (second
>> patch).
>> 
>
> FWIW nothing note worthy in my tests, as expected.
> Tested-by: Christian Loehle <christian.loehle@....com>

Same here.
Most results were within +/- 3%.

I made a mistake and didn't include one patch, and had to go back and re-do
many tests.

No need to read further unless you want to.

System:
Processor: Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz, 6 cores 12 CPUs.
CPU frequency scaling driver: intel_pstate; Governor performance.
HWP: Enabled.

Kernel: 6.18-rc4, to be able to re-use some previous test results.

Patch legend:
0ed8b4d13e03 (HEAD -> ver-2) cpuidle: governors: teo: Rework the handling of tick wakeups   <<< ver3
2ae756ea9507 sched/idle: disable tick in idle=poll idle entry    <<< ver2
5a0b904e467b cpuidle: governors: teo: Simplify intercepts-based state lookup
390ef7a94166 cpuidle: governors: teo: Fix tick_intercepts handling in teo_update()
fcfd905b2d92 cpuidle: governors: teo: Decay metrics below DECAY_SHIFT threshold   <<< rc4-rjw
870005165dd8 cpuidle: governors: teo: Use s64 consistently in teo_update()
538e62c2304b cpuidle: governors: teo: Drop redundant function parameter
4c5e9f0c553b cpuidle: governors: teo: Drop incorrect target residency check
6146a0f1dfae (tag: v6.18-rc4, origin/master, origin/HEAD, master) Linux 6.18-rc4   <<< rc4-teo

Interesting result 1: 6 ping pong pairs, no work per token stop, 105,000,000 loops:
rc4-teo:	Average: 5.53143 uSec per loop
rc4-rjw:	Average: 5.50305 uSec per loop -0.51% (Better)
ver2:	Average: 4.71545 uSec per loop -14.75%
ver3:	Average: 4.75843 uSec per loop -13.97%
Idle state 0 residency goes from about <1% for the first 2 tests to about 18% for the last 2 tests.
Idle state 1 residency goes from about 27% for the first 2 tests to about 0% for the last 2 tests.

Interesting result 2: 12 CPU token passing ring with a specific work packet per token stop:
Times are uSec/loop.

rc4-teo:
test runs: 286
average	1407.054587 reference
max	1504.4721
min	1191.2274
range	313.2447

rc4-rjw:
test runs: 606
average	1436.159564 +2.07% (worse)
max	1528.4379
min	1197.0521
range	331.3858

ver2:
test runs: 256
average	1477.551961 +5.01% (worse)
max	1537.4085
min	1295.7111
range	241.6974

ver3:
test runs: 156
average	1161.19326 -17.47% (better)
max	1241.5409
min	1152.9638
range	88.5771 

Idle state 1 Residency is about 9% for ver3 verses 3.5% for ver2
" cpuidle: governors: teo: Rework the handling of tick wakeups" pushes out the idle state transition as a function of the work packet per stop.
This operating point was cherry picked from a test that varied work per token stop over a wide range.

Interesting result 3: adrestia test:
While the actual test results were uneventful, looking at the tail of the wakeup time histogram revealed a tightening with ver3.
Such an improvement wouldn't show up in the 90th percentile, witch is declared as the wakeup latency.
See the attached detail graph.

For completeness, results (times are uSec):
rc4-teo-2.txt:	entries:	2000000	min: 2417	ave: 2655	90th percentile:	2739	max:	347648
rc4-teo.txt:	entries:	2000000	min: 2433	ave: 2649	90th percentile:	2745	max:	12339
ver2.txt:	entries:	2000000	min: 2302	ave: 2630	90th percentile:	2724	max:	12382
ver3.txt		entries:	2000000	min: 2450	ave: 2652	90th percentile:	2727	max:	12297
ver3-2.txt:	entries:	2000000	min: 2409	ave: 2668	90th percentile:	2751	max:	13663
ver3-3.txt:	entries:	2000000	min: 2391	ave: 2644	90th percentile:	2714	max:	11554

... Doug

Download attachment "histogram-detail-b.png" of type "image/png" (70070 bytes)