Messages in this thread | | | Date | Mon, 29 Aug 2022 07:13:03 +0200 | Subject | Re: [PATCH 1/2] sched/fair: Check if prev_cpu has highest spare cap in feec() | From | Dietmar Eggemann <> |
| |
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>
[...]
| |