Re: RE: [PATCH v1] cpuidle: governors: menu: Predict longer idle time when in doubt

Christian Loehle
2025-10-19T14:45:55Z

On 10/18/25 16:10, Doug Smythies wrote:
> Hi all,
>
> I have been following and testing these menu.c changes over the last months,
> but never reported back on this email list because:
> 1.) I never found anything significant to report.
> 2.) I always seemed to be a week or more behind the conversations.

Your input is always appreciated!

>
> On 2025.10.18 04:47 Rafael wrote:
>> On Fri, Oct 17, 2025 at 8:37 PM Christian Loehle wrote:
>>> On 10/17/25 10:39, Rafael J. Wysocki wrote:
>>>> On Fri, Oct 17, 2025 at 10:22 AM Christian Loehle wrote:
>>>>> On 10/16/25 17:25, Rafael J. Wysocki wrote:
>>>>>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>>>>
>>>>>> It is reported that commit 85975daeaa4d ("cpuidle: menu: Avoid discarding
>>>>>> useful information") led to a performance regression on Intel Jasper Lake
>>>>>> systems because it reduced the time spent by CPUs in idle state C7 which
>>>>>> is correlated to the maximum frequency the CPUs can get to because of an
>>>>>> average running power limit [1].
>
> I would like to understand Sergey's benchmark test better, and even try
> to repeat the results on my test system. I would also like to try to
> separate the variables in an attempt to isolate potential contributors.
>
> To eliminate the PL1 effect, limit the CPU frequency to 2300 MHz and repeat
> the test. To eliminate potential CPU frequency scaling contributions, use the
> performance CPU frequency scaling governor. Both changes at once would
> be an acceptable first step.
>
> Sergey: Would you be willing to do that test?
> Sergey: Could you provide more details about your test?

+1
Depending on what the actual test does maybe offlining CPUs and comparing would
be interesting too (if this means that we never reach throttling on this system).

>
>>From the turbostat data of the other day, it seems that the system was
> only power throttled for about 25 seconds for each test. What we don't know
> is how long the test took overall or the magnitude of any contributions from
> the power limit throttling.

If I didn't mess up it should be >800s, at least from the sum of idle time
Sergey provided. (excludes active time)
That makes the powerthrottling story less plausible IMO.

>
> Extracted PL1 area from the turbostat data:
>
> cpu0: PKG Limit #1: ENabled (6.000000 Watts, 28.000000 sec, clamp ENabled)
>
> MHz Power
> Sample revert base revert base
> 17 1150 3039 2.15 9.49 <<< base over power limit
> 18 2898 3086 6.26 8.63 <<< revert over power limit
> 19 2968 3017 8.67 9.07
> 20 3054 2642 8.22 7.47
> 21 2910 2510 9 5.57 <<< base throttled
> 22 2950 2438 8.62 5.74
> 23 2300 2571 5.61 5.67 <<< revert throttled
> 24 2423 2667 5.81 6.01
> 25 2560 1827 5.65 2.81 <<< base not throttled
> 26 2478 829 5.5 1.84
> 27 1552 992 2.36 1.86 <<< revert not throttled
>
>>From my testing of kernels 6.17-rc1, rc2,rc3 in August and September:
>
> 779b1a1cb13a cpuidle: governors: menu: Avoid selecting states with too much latency - v6.17-rc3
> fa3fa55de0d6 cpuidle: governors: menu: Avoid using invalid recent intervals data - v6.17-rc2
> baseline reference: v6.17-rc1
> d4a7882f93bf cpuidle: menu: Optimize bucket assignment when next_timer_ns equals KTIME_MAX - v6.16-rc1
>
> there was an area of about 11% regression in the 2 core ping-pong sweep test.
> After modifying the PL1 limits on my test system so that it would engage for the entire test,
> I re-ran the test with kernel 6.18-rc1 (ref) and also with this patch (rjw).
> The results were identical for each test.
> Some supporting graphs are attached.
>
>>>>>> [snip]
>>>>> [snip]
>>>>> Anyway, the patch makes sense, let me run some tests and get back.
>>>>
>>>> Thanks!
>>>
>>> Unfortunately this patch regresses my tests about as much as a revert of
>>> 85975daeaa4d would.
>>> (menu-1 is $SUBJECT, menu-m current mainline, menu-r mainline with
>>> 85975daeaa4d reverted):
>
> So I could better understand the magnitudes of things,
> Christain's test results averaged and restated:
>
> Averages: % regression
> mmcblk1 menu-1 1502.3 36.3%
> menu-m 2356.7
> menu-r 1483.3 37.1%
>
> mmcblk2 menu-1 3389.0 41.1%
> menu-m 5754.7
> menu-r 3438.3 40.3%
>
> nvme0n1 menu-1 5812.0 47.4%
> menu-m 11059.0
> menu-r 5386.7 51.3%
>
> sda menu-1 934.7 42.6%
> menu-m 1629.3
> menu-r 907.3 44.3%
>
> nullb0 menu-1 101466.0 0.1%
> menu-m 101559.7
> menu-r 101708.0 -0.1%
>
> mtdblock3 menu-1 158.7 29.2%
> menu-m 224.0
> menu-r 142.7 36.3%
>
> So, except for nulb0 pretty significant.

(nullb0 is just some sanity check, cpuidle shouldn't really ever
play a role here FWIW)
Thanks for summarising, next time it'll come with such a summary as well.

>
> Whereas Sergey's results are the other way around by similar magnitudes.
>
> 6.1-base: 84.5 +42.0%
> 6.1-base-fixup: 76.5 +28.5%
> 6.1-revert: 59.5
> backport: 78.5 +31.9%
>