linux-kernel - Re: stable 6.6: commit "sched/cpufreq: Rework schedutil governor performance estimation' causes a regression

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: <7980c3b8-46fa-4c78-b000-60d678854620@arm.com>
Date: Wed, 26 Nov 2025 09:35:17 +0000
From: Lukasz Luba <lukasz.luba@....com>
To: Yu-Che Cheng <giver@...omium.org>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
 Vincent Guittot <vincent.guittot@...aro.org>,
 Christian Loehle <christian.loehle@....com>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 Viresh Kumar <viresh.kumar@...aro.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Tomasz Figa <tfiga@...omium.org>, stable@...r.kernel.org,
 linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
 Dietmar Eggemann <dietmar.eggemann@....com>
Subject: Re: stable 6.6: commit "sched/cpufreq: Rework schedutil governor
 performance estimation' causes a regression

Hi Yu-Che,

On 11/25/25 13:01, Yu-Che Cheng wrote:
> Hi Lukasz,
> 

[snip]

>>
>> There are some differences, though:
>> 1. there are more deeps in the freq in time, so more often you would
>>      pay extra penalty for the ramp-up again
>> 2. some of the ramp-up phases are a bit longer ~100ms instead of ~80ms
>>      going from 2GHz to 3.6GHz
> 
> Agree. From the visualized frequency changes in the Perfetto traces,
> it's more obvious that the ramp-up from 2GHz to 3.6GHz becomes much
> slower and a bit unstable in v6.6.99, and it's also easier to go down
> to a low frequency after a short idle.
> 

[snip]

>>
>> I wonder if you had a fix patch for the util_est in your kernel...
>> That fix has been recently backported to 6.6 stable [1].
>>
>> You might want to try that patch as well, w/ or w/o this revert.
>> IMHO it might be worth to have it on top. It might help
>> the main Chrome task ('CrRendererMain') to stay longer on the biggest
>> cpu, since the util_est would be higher. You can read the discussion
>> that I had back then with PeterZ and VincentG [2].
> 
> No, the util_est fix isn't in our kernel yet.
> It looks like after cherry-picking the fix, without the revert, the
> Speedometer 2.0 score becomes even slightly higher than that on
> v6.6.88 (450 ~ 460 vs 435 ~ 440).
> On the other hand, with both the fix and the revert, the Speedometer
> score becomes about 475 ~ 480, which is almost the same as using the
> performance governor (i.e. pinning at the maximum frequency).

Sounds really good to get such score.

> It looks like more tasks that originally run on the little cores are
> migrated to the middle and big cores more often, which also makes CPU7
> more likely to stay at a higher frequency during some short idle in
> the main thread.

Yes, that's the desired behavior.

> 
> Also attach the Perfetto trace for both of them:
> 
> fix without revert:
> https://ui.perfetto.dev/#!/?s=ff4d10bd58982555eada61648786adf6f7187ac3
> fix with revert:
> https://ui.perfetto.dev/#!/?s=05da3cedfb3851ad694f523ef59d3cd1092d74ae

Thanks for the traces, there are idle periods there as well - cool.

I will link your email with the results for the history in that stable
patch backport.

Thanks for sharing those tests' scores. Community works :)

Regards,
Lukasz