ANDROID: Add find_best_target to minimise energy calculation overhead
find_best_target started life as an optimised energy cpu selection
algorithm designed to be efficient and high performance and integrate
well with schedtune and userspace cpuset configuration. It has had many
many small tweaks over time, and the version added here is forward
ported from the version used in android-4.4 and android-4.9. The linkage
to the rest of EAS is slightly different, however.
This version is split into the three main use-cases and addresses
them in priority order:
A) latency sensitive tasks
B) non latency sensitive tasks on IDLE CPUs
C) non latency sensitive tasks on ACTIVE CPUs
Case A) Latency sensitive tasks
Unconditionally favoring tasks that prefer idle CPU to improve latency.
When we do enter here, we are looking for:
- an idle CPU, whatever its idle_state is, since the first CPUs we
explore are more likely to be reserved for latency sensitive tasks.
- a non idle CPU where the task fits in its current capacity and has
the maximum spare capacity.
- a non idle CPU with lower contention from other tasks and running at
the lowest possible OPP.
The last two goals try to favor a non idle CPU where the task can run
as if it is "almost alone". A maximum spare capacity CPU is favored
since the task already fits into that CPU's capacity without waiting for
an OPP change.
For any case other than case A, we avoid CPUs which would become
overutilized if we placed the task there.
Case B) Non latency sensitive tasks on IDLE CPUs.
Find an optimal backup IDLE CPU for non latency sensitive tasks.
Here we are looking for:
- minimizing the capacity_orig,
i.e. preferring LITTLE CPUs
If IDLE cpus are available, we prefer to choose one in order to spread
tasks and improve performance.
Case C) Non latency sensitive tasks on ACTIVE CPUs.
Pack tasks in the most energy efficient capacities.
This task packing strategy prefers more energy efficient CPUs (i.e.
pack on smaller maximum capacity CPUs) while also trying to spread
tasks to run them all at the lower OPP.
This assumes for example that it's more energy efficient to run two tasks
on two CPUs at a lower OPP than packing both on a single CPU but running
that CPU at an higher OPP.
This code has had many other contributors over the development listed
here as Cc.
Cc: Ke Wang <ke.wang@spreadtrum.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Patrick Bellasi <patrick.bellasi@arm.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Srinath Sridharan <srinathsr@google.com>
Cc: Todd Kjos <tkjos@google.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: Chris Redpath <chris.redpath@arm.com>
(cherry picked from commit f240e44406558b17ff7765f252b0bcdcbc15126f)
[ - Removed tracepoints
- Took capacity_curr_of() from "7f6fb82 ANDROID: sched: EAS: take
cstate into account when selecting idle core"
- Re-use sd_ea from find_energy_efficient_cpu() / removed start_cpu()
- Mark candidates with a cpumask given by feec()
- Squashed Ionela's tri-gear fbt fixes from android-4.14
- Squashed Patrick's changes related to util_est from android-4.14 ]
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Change-Id: I9500d308c879dd53b08adeda8f988238e39cc392
2 files changed
