Re: [PATCH v2] sched/fair: Fix cpu_util runnable_avg arithmetic
From: Dietmar Eggemann
Date: Fri Jun 05 2026 - 06:45:20 EST
On 05.06.26 11:43, Hongyan Xia wrote:
> From: Hongyan Xia <hongyan.xia@xxxxxxxxxxxxx>
>
> If we take runnable_avg in max(runnable_avg, util_avg) in cpu_util(), we
> should then add or subtract task runnable_avg, but the arithmetic below
> is still with task util_avg. This mixes runnable_avg with util_avg which
> is incorrect.
>
> Fix by always doing arithmetic with runnable_avg and only take
> max(runnable_avg, util_avg) at the last step.
>
> Fixes: 7d0583cf9ec7 ("sched/fair, cpufreq: Introduce 'runnable boosting'")
> Signed-off-by: Hongyan Xia <hongyan.xia@xxxxxxxxxxxxx>
Does this fix the issue in EAS energy calculation you mentioned
initially? We now add/subtract task rbl_avg from CPU rbl_avg but can we
now use this value correctly in util_avg based EAS?
How do you want to solve the power consumption regression in you
low-power use cases? Since you mentioned per-CPU tasks in those
contention scenarios (per-CPU worker vs producer *), do you plan to only
use boost in cpu_util() in case the affinity of p (worker) is not
constrained? Not sure whether the consumer (CPU affinity not
constrained) also has rbl_avg > util_avg?
*
https://lore.kernel.org/r/4adbab4d-f9e4-4354-aa1e-48f11b1fd208@xxxxxxxxxxxxx
[...]