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

[Pierre Gondois]

Hello Peter,

The second patch:
 -[PATCH 2/2] sched/fair: Use IRQ scaling for all sched classes
must be dropped, cf. Vincent Guittot's review, but I believe this patch
should be ok to take if there is no other comment,

Regards,
Pierre

On 8/29/22 07:13, Dietmar Eggemann wrote:
> 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@xxxxxxx>
>
> 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@xxxxxxx>
>
> [...]