linux-kernel - Re: stable: commit "cpuidle: menu: Avoid discarding useful information" causes regressions

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <49cf14a1-b96f-4413-a17e-599bc1c104cd@arm.com>
Date: Tue, 14 Oct 2025 16:11:09 +0100
From: Christian Loehle <christian.loehle@....com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>,
 Sasha Levin <sashal@...nel.org>, Daniel Lezcano <daniel.lezcano@...aro.org>,
 linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
 Tomasz Figa <tfiga@...omium.org>, stable@...r.kernel.org
Subject: Re: stable: commit "cpuidle: menu: Avoid discarding useful
 information" causes regressions

On 10/14/25 12:55, Sergey Senozhatsky wrote:
> On (25/10/14 11:25), Christian Loehle wrote:
>> On 10/14/25 11:23, Sergey Senozhatsky wrote:
>>> On (25/10/14 10:50), Christian Loehle wrote:
>>>>> Upstream fixup fa3fa55de0d ("cpuidle: governors: menu: Avoid using
>>>>> invalid recent intervals data") doesn't address the problems we are
>>>>> observing.  Revert seems to be bringing performance metrics back to
>>>>> pre-regression levels.
>>>>
>>>> Any details would be much appreciated.
>>>> How do the idle state usages differ with and without
>>>> "cpuidle: menu: Avoid discarding useful information"?
>>>> What do the idle states look like in your platform?
>>>
>>> Sure, I can run tests.  How do I get the numbers/stats
>>> that you are asking for?
>>
>> Ideally just dump
>> cat /sys/devices/system/cpu/cpu*/cpuidle/state*/*
>> before and after the test.
> 
> OK, got some data for you.  The terminology being used here is as follows:
> 
> - 6.1-base
>   is 6.1 stable with a9edb700846 "cpuidle: menu: Avoid discarding useful information"
> 
> - 6.1-base-fixup
>   is 6.1 stable with a9edb700846 and fa3fa55de0d6 "cpuidle: governors:
>   menu: Avoid using invalid recent intervals data" cherry-pick
> 
> - 6.1-revert
>   is 6.1 stable with a9edb700846 reverted (and no fixup commit, obviously)
> 
> Just to show the scale of regression, results of some of the benchmarks:
> 
>   6.1-base:		84.5
>   6.1-base-fixup:	76.5
>   6.1-revert:		59.5
> 
>   (lower is better, 6.1-revert has the same results as previous stable
>   kernels).
This immediately threw me off.
The fixup was written for a specific system which had completely broken
cpuidle. It shouldn't affect any sane system significantly.
I double checked the numbers and your system looks fine, in fact none of
the tests had any rejected cpuidle occurrences. So functionally base and
base-fixup are identical for you. The cpuidle numbers are also reasonably
'in the noise', so just for the future some stats would be helpful on those
scores.

I can see a huge difference between base and revert in terms of cpuidle,
so that's enough for me to take a look, I'll do that now.
(6.1-revert has more C3_ACPI in favor of C1_ACPI.)

(Also I can't send this email without at least recommending teo instead of menu
for your platform / use-cases, if you deemed it unfit I'd love to know what
didn't work for you!)