+308
−158
+3
−0
Loading
ANDROID: sched/fair: re-factor energy_diff to use a single (extensible) energy_env
The energy_env data structure is used to cache values required by multiple
different functions involved in energy_diff computation. Some of these
functions require additional parameters which can be easily embedded
into the energy_env itself. The current implementation of energy_diff
hardcodes the usage of two different energy_env structures to estimate and
compare the energy consumption related to a "before" and an "after" CPU.
Moreover, it does this energy estimation by walking multiple times the
SDs/SGs data structures.
A better design can be envisioned by better using the energy_env structure
to support a more efficient and concurrent evaluation of multiple schedule
candidates. To this purpose, this patch provides a complete re-factoring
of the energy_diff implementation to:
1. use a single energy_env structure for the evaluation of all the
candidate CPUs
2. walk just one time the SDs/SGs, thus improving the overall performance
to compute the energy estimation for each CPU candidate specified by
the single used energy_env
3. simplify the code (at least if you look at the new version and not at
this re-factoring patch) thus providing a more clean code to maintain
and extend for additional features
This patch updated all the clients of energy_env to use only the data
provided by this structure and an index for one of its CPUs candidates.
Embedding everything within the energy env will make it simple to add
tracepoints for this new version, which can easily provide an holistic
view on how energy_diff evaluated the proposed CPU candidates.
The new proposed structure, for both "struct energy_env" and the functions
using it, is designed in such a way to easily accommodate additional
further extensions (e.g. SchedTune filtering) without requiring an
additional big re-factoring of these core functions.
The semantics of energy_diff is now changed to return the index of the
most energy efficient CPU candidate, among the ones specified in the
energy_env structure, being 0 the index of the task's previous CPU,
(i.e. EAS_CPU_PRV). Thus, the name of this function has also been
updated to be:
select_energy_cpu_idx(eenv)
The usage of a CPUs candidate array, embedded into the energy_diff
structure allows seamless exploration of all possible candidate CPUs,
so as to maintain the brute placement strategy for non-prefer-idle
tasks. This can evaluate the effectiveness of spread/pack strategies
automatically for all possible placements.
Also includes:
ANDROID: sched/fair: Sync task util before EAS wakeup
Before using a task's util_avg signal in EAS, we need to ensure that
it has been synced up to the last_update_time of prev_cpu's root
cfs_rq.
We previously relied on the side effect of wake_cap to do that,
however that does not happen when the waking CPU has the same
capacity as the prev_cpu. Therefore just explicitly call
sync_entity_load_avg. This may result in calling that function twice
within the same select_task_rq_fair, but since last_update_time
hasn't changed the second call will bail out very quickly.
In previous integrations of EAS for Android, we had a patch from
Joonwoo Park <joonwoop@codeaurora.org>
which kept energy calculations at full resolution for part of
the calculation.
The original commit log was:
sched: EAS: fix incorrect energy delta calculation due
to rounding error
In order to calculate energy difference we currently iterates
CPUs under the same sched doamin to accumulate total energy
cost and compare before and after. Energy is shifted down as it
is accumulated.
Doing such can incorrectly calculate and report abs(delta) > 0
when there is actually no energy delta between before and after
because the same total accumulated cpu_util of all the CPUs can
be distributed differently before and after and it causes
different amount of rounding error.
Fix such incorrectness by shifting just once with accumulated
total_energy.
Signed-off-by: 
Joonwoo Park <joonwoop@codeaurora.org>
When reimplementing this for 4.14 I decided we should never bother
to shift the value down except when we print it since we only ever
compare the value we calculate and the absolute value doesn't matter.
Also, since c32055a4ff68
"UPSTREAM: sched/fair: Sync task util before slow-path wakeup"
we no longer need to update the utilization signals in energy-aware
wakeup, once we have refactored it to happen at the bottom of
select_task_rq_fair so this patch does not include the usual
signal sync in energy-aware functions.
Change-Id: I3ae8e630f5674739d9cf059a82609b113aaffb2f
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
(integrated with brute wakeup and 4.14)
Signed-off-by: Chris Redpath <chris.redpath@arm.com>