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

["Doug Smythies" <dsmythies@telus.net>]

On 2025.10.20 20:43 Sergey Senozhatsky wrote:
> On (25/10/18 08:10), Doug Smythies wrote:
>> 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?
>
> Apologies for the delay.
>
> Sure, I can give it a try sometime this week, am dealing with a bunch
> of other stable regressions right now (will report separately).
>
> Can you please help me with the configuration steps?  CPU freq limiting,
> etc.

For your system booted with "base" and "revert" do:

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
echo 2300000 | sudo tee /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq

then do your test.

>
>> Sergey: Could you provide more details about your test?
>
> We track regressions in a number of tests.  The one I'm running more
> often than others is a Google Docs test (our tests replicate real use
> cases).  The test in question creates new google docs (in chrome, of
> course) and inputs some text in them (with various words-per-minute
> settings - 60, 90, 120 wpm) in English, Japanese, Korean and other
> languages; different font faces, different styles (bold, italic),
> text highlighting/selection, windows switching, and so on.  The test
> measures input latency, the number of dropped frames during scrolling,
> CPU usage, power consumption, etc.

Okay, Thanks. So not a test I can repeat on my test computer.

... Doug