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

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

[-- Attachment #1: Type: text/plain, Size: 3851 bytes --]

On 2026.02.04 16:45 Doug Smythies wrote:
> On 2026.02.03 08:46 Rafael J. Wysocki wrote:
>> 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?

Further to my earlier email, there is an interesting area in Sergey's turbostat data from
October. It is not near any throttling threshold, yet the CPU frequencies are considerably
higher for the "revert" case verses "base", with everything seemingly similar. I do not
understand this area. An annotated graph is attached.

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


[-- Attachment #2: interesting-area.png --]
[-- Type: image/png, Size: 237347 bytes --]