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 for Android: free password hash cracker in your pocket

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

Message-ID: <x4qvjfwxzatm6wnrtqgue7y673oqzo74i6ysmxalvnts5olkot@ekaee62fjg5l>
Date: Tue, 21 Oct 2025 12:43:11 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Doug Smythies <dsmythies@...us.net>
Cc: "'Rafael J. Wysocki'" <rafael@...nel.org>, 
	'Christian Loehle' <christian.loehle@....com>, 'Sergey Senozhatsky' <senozhatsky@...omium.org>, 
	'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: [PATCH v1] cpuidle: governors: menu: Predict longer idle time
 when in doubt

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.

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