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

[Dietmar Eggemann]

On 04.06.26 11:21, Hongyan Xia wrote:
> On 6/4/2026 4:48 PM, Vincent Guittot wrote:
>> On Thu, 4 Jun 2026 at 10:21, Hongyan Xia <hongyan.xia@xxxxxxxxxxxxx> wrote:
>>>
>>> On 6/4/2026 3:42 PM, Vincent Guittot wrote:
>>>> On Thu, 28 May 2026 at 04:36, Hongyan Xia <hongyan.xia@xxxxxxxxxxxxx> wrote:
>>>>>
>>>>> From: Hongyan Xia <hongyan.xia@xxxxxxxxxxxxx>

[...]

>>>>> Analysis:
>>>>>
>>>>> We found several problems that result in the power spike:
>>>>>
>>>>> 1. Arithmetic should not happen between util_avg and runnable_avg:
>>>>>
>>>>> After util = max(util, runnable) which potentially picks runnable value
>>>>> in cpu_util(), we then add or subtract task util values from it. This
>>>>> produces a value that is half-runnable-half-util which is ill-defined.
>>>>> This alone should be a warning sign. This breaks EAS calculations in
>>>>> many cases, leading to sub-optimal task placements.
>>>>
>>>> This can be easily fixed
>>>
>>> I thought about adding or subtracting runnable_avg instead, but that is
>>> still wrong. Given three tasks each with 100 util, if they wake up at
>>> the same time and running on the same rq, their util is 100, 100, 100,
>>> rq total util is 300. Their runnable_avg is 100, 200, 300, rq total
>>> runnable_avg is 600. If the 1st task leaves the rq, the remaining two
>>> task runnable_avg will then become 100, 200, giving a total rq
>>> runnable_avg of 300. However, subtracting the runnable_avg of the 1st
>>> task gives 600 - 100 = 500, which is very wrong.
>>
>> Substracting/adding se.avg.runnable_avg is still the right solution
>> because this is what will happen if the task migrate
> 
> One difference is that before runnable boost, runnable_avg really 
> doesn't affect EAS and CPUFreq much. Runnable boost is the first 
> instance where we directly use raw runnable_avg values in EAS and 
> frequency selection, and this value is often too high to be reasonable. 
> I'm mostly arguing that we should use it in proper places (like the one 
> in util_est_update()) and not here.
> 
> Actually this is the very first fix we tried internally. There is minor 
> improvement in EAS spreading out tasks, but energy regression is pretty 
> much the same, and Youtube is still at 20% regression.

I thought the issue was that, in your low-power test cases, most of the
tasks involved in these contention scenarios are raising CPU frequency,
but they are not directly contributing to the workload (including
Android Graphics Pipeline (AGP) progress). If that's the case, the
additional power consumption is essentially wasted.

Could you collect some information about these contention events and
identify the tasks involved?

By the way, I still assume that all per-task ADPF boosting (including
AGP boosting) is disabled on your system. I also assume that the number
of janky frames is negligible, since you're only showing FPS data.

[...]