Messages in this thread | | | Date | Mon, 26 Sep 2022 14:13:23 +0200 | Subject | Re: [PATCH 1/2] sched/fair: Check if prev_cpu has highest spare cap in feec() | From | 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@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> > > [...]
| |