Message-ID: <8ccf53bd-81cc-4c7b-88b5-5d7aeebf2c3f@arm.com>
Date: Sun, 19 Oct 2025 15:45:45 +0100
From: Christian Loehle <christian.loehle@....com>
To: Doug Smythies <dsmythies@...us.net>,
 "'Rafael J. Wysocki'" <rafael@...nel.org>,
 'Sergey Senozhatsky' <senozhatsky@...omium.org>
Cc: 'Linux PM' <linux-pm@...r.kernel.org>,
 'LKML' <linux-kernel@...r.kernel.org>,
 'Artem Bityutskiy' <artem.bityutskiy@...ux.intel.com>,
 'Tomasz Figa' <tfiga@...omium.org>
Subject: Re: RE: [PATCH v1] cpuidle: governors: menu: Predict longer idle time
 when in doubt

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@...el.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%
> 

Powered by blists - more mailing lists