Re: [PATCH v2] sched/fair: Fix cpu_util runnable_avg arithmetic

[Dietmar Eggemann <dietmar.eggemann@arm.com>]

On 05.06.26 11:43, Hongyan Xia wrote:
> From: Hongyan Xia <hongyan.xia@transsion.com>
> 
> 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@transsion.com>

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@transsion.com


[...]