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

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: <001201dc4297$3903af70$ab0b0e50$@telus.net>
Date: Tue, 21 Oct 2025 07:30:17 -0700
From: "Doug Smythies" <dsmythies@...us.net>
To: "'Sergey Senozhatsky'" <senozhatsky@...omium.org>
Cc: "'Rafael J. Wysocki'" <rafael@...nel.org>,
	"'Christian Loehle'" <christian.loehle@....com>,
	"'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>,
	"Doug Smythies" <dsmythies@...us.net>
Subject: RE: [PATCH v1] cpuidle: governors: menu: Predict longer idle time when in doubt

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@...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?
>
> 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