Re: [PATCH 1/2] sched/fair: Check if prev_cpu has highest spare cap in feec()

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

On 19/08/2022 17:33, Pierre Gondois wrote:
> When evaluating the CPU candidates in the perf domain (pd) containing
> the previously used CPU (prev_cpu), find_energy_efficient_cpu()
> evaluates the energy of the pd:
> - without the task (base_energy)
> - with the task placed on prev_cpu (if the task fits)
> - with the task placed on the CPU with the highest spare capacity,
>   prev_cpu being excluded from this set
> 
> If prev_cpu is already the CPU with the highest spare capacity,
> max_spare_cap_cpu will be the CPU with the second highest spare
> capacity.
> 
> On an Arm64 Juno-r2, with a workload of 10 tasks at a 10% duty cycle,
> when prev_cpu and max_spare_cap_cpu are both valid candidates,
> prev_spare_cap > max_spare_cap at ~82%.
> Thus the energy of the pd when placing the task on max_spare_cap_cpu
> is computed with no possible positive outcome 82% most of the time.
> 
> Do not consider max_spare_cap_cpu as a valid candidate if
> prev_spare_cap > max_spare_cap.
> 
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>

LGTM. When I ran the workload I see this happening in 50%-90% of the EAS
wakeups. This should prevent one needless compute_energy() call out of 7
on a typical 3-gear system like 2x2x4 in these cases.

Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>

[...]