tree 2b58b881256dcfe82069c71bdadd8af72c0d433c
parent 7565bcb84a77a0ab6f38ffb125d52ee42ae8b9f1
author Quentin Perret <quentin.perret@arm.com> 1551266484 +0000
committer Quentin Perret <qperret@google.com> 1575281037 +0000

ANDROID: sched/fair: Bias EAS placement for latency

Add to find_energy_efficient_cpu() a latency sensitive case which mimics
what was done for prefer-idle in android-4.19 and before (see [1] for
reference).

This isn't strictly equivalent to the legacy algorithm but comes real
close, and isn't very invasive. Overall, the idea is to select the
biggest idle CPU we can find for latency-sensitive boosted tasks, and
the smallest CPU where the can fit for latency-sensitive non-boosted
tasks.

The main differences with the legacy behaviour are the following:

 1. the policy for 'prefer idle' when there isn't a single idle CPU in
    the system is simpler now. We just pick the CPU with the highest
    spare capacity;

 2. the cstate awareness is implemented by minimizing the exit latency
    rather than the idle state index. This is how it is done in the slow
    path (find_idlest_group_cpu()), it doesn't require us to keep hooks
    into CPUIdle, and should actually be better because what we want is
    a CPU that can wake up quickly;

 3. non-latency-sensitive tasks just use the standard mainline
    energy-aware wake-up path, which decides the placement using the
    Energy Model;

 4. the 'boosted' and 'latency_sensitive' attributes of a task come from
    util_clamp (which now replaces schedtune).

[1] https://android.googlesource.com/kernel/common.git/+/c27c56105dcaaae54ecc39ef33fbfac87a1486fc

Change-Id: Ia58516906e9cb5abe08385a8cd088097043d8703
Signed-off-by: Quentin Perret <quentin.perret@arm.com>