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

[Dietmar Eggemann]

On 22.05.26 11:36, hongyan.xia wrote:
> On 5/22/2026 3:49 PM, Dietmar Eggemann wrote:
>> On 18.05.26 04:40, hongyan.xia(夏弘彦) wrote:
>>> From: Hongyan Xia <hongyan.xia@xxxxxxxxxxxxx>

[...]

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

OK.

Would be interesting to know how this 'avoid janks' feature can be
disabled. So all ADPF ('Performance Hints' and/or 'Performance boost for
games') hints are off? And this can be achieved by simply stripping all
Vendor Hooks?
I haven't looked at this for quite some time so I don't know how this is
all wired up and how to disable this.

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

Ah, OK. But this condition in util_est_update() does this on individual
task level:

  /*
   * To avoid underestimate of task utilization, skip updates of EWMA if
   * we cannot grant that thread got all CPU time it wanted.
   */
   if ((dequeued + UTIL_EST_MARGIN) < READ_ONCE(se->avg.runnable_avg))
                goto done;

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

[...]

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

OK.