Re: [PATCH] sched/fair: Revert boost in cpu_util()

[hongyan.xia <hongyan.xia@transsion.com>]

On 5/22/2026 3:49 PM, Dietmar Eggemann wrote:
> On 18.05.26 04:40, hongyan.xia(夏弘彦) wrote:
>> From: Hongyan Xia <hongyan.xia@transsion.com>
> 
> I'm on vacation this week so will have a closer look beginning of next week.

Vacation certainly more important. Patches can wait :)

>> We have seen a massive power consumption regression (20% SoC power
>> increase in many apps) after updating our kernel. After bisection we
> 
> What is the kernel version you updated to? Which one you have been using
> so far?
> 
> Are you using Android on your devices? I remember there was some
> functionality added to avoid janks in display pipeline.

Yes, this is Android but with scheduler vendor hooks stripped, so kernel 
6.6 schedutil with some GKI patches on top. There is "something to avoid 
janks", but to make sure the results can be shared upstream, such 
Android things are disabled, leaving basically vanilla schedutil.

>> pinpointed the regression to the cpu_util(boost) feature. After
>> reverting the boost feature the massive energy regression is gone.
>> Detailed trace analysis down below. The regression is found across quite
>> many apps but Youtube is one of the worst offenders, shown in the
>> 1080p60fps video benchmark:
>>
>>   Setup      FPS   SoC Power (mW)  diff
>> w/  boost  59.94      913.6
>> w/o boost  59.93      720.4     -21.15%
>>
>> Signed-off-by: Hongyan Xia <hongyan.xia@transsion.com>
>>
>> ---
>> Analysis:
> 
> [...]
> 
>> 2. Using the absolute value of runnable_avg to drive frequency is
>>     too high to be reasonable:
>>
>> We use runnable in a _relative_ way to util to know whether there is
> 
> Is this part of the value adds you put on top of mainline kernel? Are
> you able to share this here?

By 'we' I mean upstream schedutil, like the comparison in 
util_est_update between util and runnable to know whether there is 
contention. The results I shared in this thread were always run on a 
setup that doesn't include our internal stuff.

>> contention in several places. However, the _absolute_ value should not
>> be used like util. Runnable_avg tends to be significantly higher,
>> making it much easier to saturate frequency.
>>
>> For example, if three tasks each with a util of 100 contend on the same
>> rq, the rq util is 300 but runnable_avg shoots up to 900. 900 drives the
>> CPU at the max frequency, and it's highly questionable whether this
>> boost is the right decision.
> 
> Shouldn't this be max 600, in case the task's runtime overlap perfectly?
> In case they don't overlap at all runnable_avg should be util_avg. Is
> this a theoretical example or taken from your traces?

You are right, the first task that completes no longer accumulates 
runnable_avg, so the runnable_avg of the three tasks are 100, 200, 300, 
so 600 in total.

This is only a theoretical example, although in apps like Youtube 
playback we do see the average frequency hovering around 1.5x w/ boost 
than w/o boost, so in reality there is still a big difference.

>> 3. Runnable_avg may not even reflect true contention:
>>
>> When tasks are dependent, the bottleneck is often the data flow between
>> tasks, not the contention seen by runnable_avg. Boosting frequency with
>> runnable in such scenarios wastes power without performance benefits.
> 
> That's probably true. But here any global feature (which doesn't need
> per-task setup) won't be able to give perfect results, only per-task
> setup can fix this.

Our observation seems that few tasks benefit and most of our workloads 
suffer from a big energy regression, so putting this feature on the 
generic path might not be the best thing.

Christian did suggest some gaming benchmarks. Sadly our setup has a 
completely different governor for gaming. I will try to rip out 
everything and put games back on vanilla schedutil. Hopefully I will 
come back soon with gaming results.