RE: Performance regressions introduced via Revert "cpuidle: menu: Avoid discarding useful information" on 5.15 LTS

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

On 2026.02.03 08:46 Rafael J. Wysocki wrote:

-----Original Message-----
From: Rafael J. Wysocki <rafael@kernel.org> 
Sent: February 3, 2026 8:46 AM
To: Christian Loehle <christian.loehle@arm.com>
Cc: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>; Rafael J. Wysocki <rafael@kernel.org>; Doug Smythies <dsmythies@telus.net>; Sasha Levin <sashal@kernel.org>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; linux-pm@vger.kernel.org; stable@vger.kernel.org; Daniel Lezcano <daniel.lezcano@linaro.org>; Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: Performance regressions introduced via Revert "cpuidle: menu: Avoid discarding useful information" on 5.15 LTS

> On Tue, Feb 3, 2026 at 10:31 AM Christian Loehle wrote:
>> On 2/3/26 09:16, Harshvardhan Jha wrote:
>>> On 03/02/26 2:37 PM, Christian Loehle wrote:
>>>> On 2/2/26 17:31, Harshvardhan Jha wrote:
>
> [cut]
>
>>>> FWIW Jasper Lake seems to be supported from 5.6 on, see
>>>> b2d32af0bff4 ("x86/cpu: Add Jasper Lake to Intel family")
>>>
>>> Oh I see, but shouldn't avoiding regressions on established platforms be
>>> a priority over further optimizing for specific newer platforms like
>>> Jasper Lake?
>>>
>> Well avoiding regressions on established platforms is what lead to
>> 10fad4012234 Revert "cpuidle: menu: Avoid discarding useful information"
>> being applied and backported.
>> The expectation for stable is that we avoid regressions and potentially
>> miss out on improvements. If you want the latest greatest performance you
>> should probably run a latest greatest kernel.
>> The original
>> 85975daeaa4d cpuidle: menu: Avoid discarding useful information
>> was seen as a fix and overall improvement,
>
> Note, however, that commit 85975daeaa4d carries no Fixes: tag and no
> Cc: stable.  It was picked up into stable kernels for another reason.
>
>> that's why it was backported, but Sergey's regression report contradicted that.
>
> Exactly.
>
>> What is "established" and "newer" for a stable kernel is quite handwavy
>> IMO but even here Sergey's regression report is a clear data point...
>
> Which wasn't known at the time commit 85975daeaa4d went in.
>
>> Your report is only restoring 5.15 (and others) performance to 5.15
>> upstream-ish levels which is within the expectations of running a stable
>> kernel. No doubt it's frustrating either way!
>
> That is a consequence of the time it takes for mainline changes to
> propagate to distributions (Chrome OS in this particular case) at
> which point they get tested on a wider range of systems.  Until that
> happens, it is not really guaranteed that the given change will stay
> in.
>
> In this particular case, restoring commit 85975daeaa4d would cause the
> same problems on the systems adversely affected by it to become
> visible again and I don't think it would be fair to say "Too bad" to
> the users of those systems.  IMV, it cannot be restored without a way
> to at least limit the adverse effect on performance.

I have been going over the old emails and the turbostat data again and again
and again.

I still do not understand how to breakdown Sergey's results into its
component contributions. I am certain there is power limit throttling
during the test, but have no idea to much or how little it contributes to the
differing results.

I think more work is needed to fully understand Sergey's test results from October.
I struggle with the dramatic test results difference of base=84.5 and revert=59.5
as being due to only the idle code changes.

That is why I keep asking for a test to be done with the CPU clock frequency limited
such that power limit throttling can not occur. I don't know what limit to use, but suggest
2.2 GHZ to start with. Capture turbostat data with the tests. And record the test results.
@Sergey: are you willing to do the test?

>
> I have an idea to test, but getting something workable out of it may
> be a challenge, even if it turns out to be a good one.