^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) =======================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) Energy Aware Scheduling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =======================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) 1. Introduction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) ---------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) Energy Aware Scheduling (or EAS) gives the scheduler the ability to predict
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) the impact of its decisions on the energy consumed by CPUs. EAS relies on an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) Energy Model (EM) of the CPUs to select an energy efficient CPU for each task,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) with a minimal impact on throughput. This document aims at providing an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) introduction on how EAS works, what are the main design decisions behind it, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) details what is needed to get it to run.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) Before going any further, please note that at the time of writing::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) /!\ EAS does not support platforms with symmetric CPU topologies /!\
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) EAS operates only on heterogeneous CPU topologies (such as Arm big.LITTLE)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) because this is where the potential for saving energy through scheduling is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) the highest.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) The actual EM used by EAS is _not_ maintained by the scheduler, but by a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) dedicated framework. For details about this framework and what it provides,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) please refer to its documentation (see Documentation/power/energy-model.rst).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) 2. Background and Terminology
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) -----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) To make it clear from the start:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) - energy = [joule] (resource like a battery on powered devices)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) - power = energy/time = [joule/second] = [watt]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) The goal of EAS is to minimize energy, while still getting the job done. That
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) is, we want to maximize::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) performance [inst/s]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) --------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) power [W]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) which is equivalent to minimizing::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) energy [J]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) -----------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) instruction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) while still getting 'good' performance. It is essentially an alternative
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) optimization objective to the current performance-only objective for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) scheduler. This alternative considers two objectives: energy-efficiency and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) performance.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) The idea behind introducing an EM is to allow the scheduler to evaluate the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) implications of its decisions rather than blindly applying energy-saving
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) techniques that may have positive effects only on some platforms. At the same
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) time, the EM must be as simple as possible to minimize the scheduler latency
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) impact.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) In short, EAS changes the way CFS tasks are assigned to CPUs. When it is time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) for the scheduler to decide where a task should run (during wake-up), the EM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) is used to break the tie between several good CPU candidates and pick the one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) that is predicted to yield the best energy consumption without harming the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) system's throughput. The predictions made by EAS rely on specific elements of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) knowledge about the platform's topology, which include the 'capacity' of CPUs,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) and their respective energy costs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) 3. Topology information
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) -----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) EAS (as well as the rest of the scheduler) uses the notion of 'capacity' to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) differentiate CPUs with different computing throughput. The 'capacity' of a CPU
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) represents the amount of work it can absorb when running at its highest
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) frequency compared to the most capable CPU of the system. Capacity values are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) normalized in a 1024 range, and are comparable with the utilization signals of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) tasks and CPUs computed by the Per-Entity Load Tracking (PELT) mechanism. Thanks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) to capacity and utilization values, EAS is able to estimate how big/busy a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) task/CPU is, and to take this into consideration when evaluating performance vs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) energy trade-offs. The capacity of CPUs is provided via arch-specific code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) through the arch_scale_cpu_capacity() callback.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) The rest of platform knowledge used by EAS is directly read from the Energy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) Model (EM) framework. The EM of a platform is composed of a power cost table
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) per 'performance domain' in the system (see Documentation/power/energy-model.rst
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) for futher details about performance domains).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) The scheduler manages references to the EM objects in the topology code when the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) scheduling domains are built, or re-built. For each root domain (rd), the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) scheduler maintains a singly linked list of all performance domains intersecting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) the current rd->span. Each node in the list contains a pointer to a struct
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) em_perf_domain as provided by the EM framework.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) The lists are attached to the root domains in order to cope with exclusive
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) cpuset configurations. Since the boundaries of exclusive cpusets do not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) necessarily match those of performance domains, the lists of different root
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) domains can contain duplicate elements.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) Example 1.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) Let us consider a platform with 12 CPUs, split in 3 performance domains
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) (pd0, pd4 and pd8), organized as follows::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) CPUs: 0 1 2 3 4 5 6 7 8 9 10 11
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) PDs: |--pd0--|--pd4--|---pd8---|
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) RDs: |----rd1----|-----rd2-----|
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) Now, consider that userspace decided to split the system with two
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) exclusive cpusets, hence creating two independent root domains, each
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) containing 6 CPUs. The two root domains are denoted rd1 and rd2 in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) above figure. Since pd4 intersects with both rd1 and rd2, it will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) present in the linked list '->pd' attached to each of them:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) * rd1->pd: pd0 -> pd4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) * rd2->pd: pd4 -> pd8
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) Please note that the scheduler will create two duplicate list nodes for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) pd4 (one for each list). However, both just hold a pointer to the same
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) shared data structure of the EM framework.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) Since the access to these lists can happen concurrently with hotplug and other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) things, they are protected by RCU, like the rest of topology structures
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) manipulated by the scheduler.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) EAS also maintains a static key (sched_energy_present) which is enabled when at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) least one root domain meets all conditions for EAS to start. Those conditions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) are summarized in Section 6.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) 4. Energy-Aware task placement
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) ------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) EAS overrides the CFS task wake-up balancing code. It uses the EM of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) platform and the PELT signals to choose an energy-efficient target CPU during
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) wake-up balance. When EAS is enabled, select_task_rq_fair() calls
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) find_energy_efficient_cpu() to do the placement decision. This function looks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) for the CPU with the highest spare capacity (CPU capacity - CPU utilization) in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) each performance domain since it is the one which will allow us to keep the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) frequency the lowest. Then, the function checks if placing the task there could
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) save energy compared to leaving it on prev_cpu, i.e. the CPU where the task ran
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) in its previous activation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) find_energy_efficient_cpu() uses compute_energy() to estimate what will be the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) energy consumed by the system if the waking task was migrated. compute_energy()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) looks at the current utilization landscape of the CPUs and adjusts it to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) 'simulate' the task migration. The EM framework provides the em_pd_energy() API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) which computes the expected energy consumption of each performance domain for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) the given utilization landscape.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) An example of energy-optimized task placement decision is detailed below.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) Example 2.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) Let us consider a (fake) platform with 2 independent performance domains
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) composed of two CPUs each. CPU0 and CPU1 are little CPUs; CPU2 and CPU3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) are big.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) The scheduler must decide where to place a task P whose util_avg = 200
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) and prev_cpu = 0.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) The current utilization landscape of the CPUs is depicted on the graph
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) below. CPUs 0-3 have a util_avg of 400, 100, 600 and 500 respectively
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) Each performance domain has three Operating Performance Points (OPPs).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) The CPU capacity and power cost associated with each OPP is listed in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) the Energy Model table. The util_avg of P is shown on the figures
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) below as 'PP'::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) CPU util.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) 1024 - - - - - - - Energy Model
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) +-----------+-------------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) | Little | Big |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) 768 ============= +-----+-----+------+------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) | Cap | Pwr | Cap | Pwr |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) +-----+-----+------+------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) 512 =========== - ##- - - - - | 170 | 50 | 512 | 400 |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) ## ## | 341 | 150 | 768 | 800 |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) 341 -PP - - - - ## ## | 512 | 300 | 1024 | 1700 |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) PP ## ## +-----+-----+------+------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) 170 -## - - - - ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) ## ## ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) ------------ -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) CPU0 CPU1 CPU2 CPU3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) Current OPP: ===== Other OPP: - - - util_avg (100 each): ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) find_energy_efficient_cpu() will first look for the CPUs with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) maximum spare capacity in the two performance domains. In this example,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) CPU1 and CPU3. Then it will estimate the energy of the system if P was
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) placed on either of them, and check if that would save some energy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) compared to leaving P on CPU0. EAS assumes that OPPs follow utilization
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) (which is coherent with the behaviour of the schedutil CPUFreq
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) governor, see Section 6. for more details on this topic).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) **Case 1. P is migrated to CPU1**::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) 1024 - - - - - - -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) Energy calculation:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) 768 ============= * CPU0: 200 / 341 * 150 = 88
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) * CPU1: 300 / 341 * 150 = 131
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) * CPU2: 600 / 768 * 800 = 625
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) 512 - - - - - - - ##- - - - - * CPU3: 500 / 768 * 800 = 520
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) ## ## => total_energy = 1364
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) 341 =========== ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) PP ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) 170 -## - - PP- ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) ## ## ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) ------------ -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) CPU0 CPU1 CPU2 CPU3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) **Case 2. P is migrated to CPU3**::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) 1024 - - - - - - -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) Energy calculation:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) 768 ============= * CPU0: 200 / 341 * 150 = 88
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) * CPU1: 100 / 341 * 150 = 43
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) PP * CPU2: 600 / 768 * 800 = 625
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) 512 - - - - - - - ##- - -PP - * CPU3: 700 / 768 * 800 = 729
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) ## ## => total_energy = 1485
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) 341 =========== ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) 170 -## - - - - ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) ## ## ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) ------------ -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) CPU0 CPU1 CPU2 CPU3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) **Case 3. P stays on prev_cpu / CPU 0**::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) 1024 - - - - - - -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) Energy calculation:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) 768 ============= * CPU0: 400 / 512 * 300 = 234
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) * CPU1: 100 / 512 * 300 = 58
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) * CPU2: 600 / 768 * 800 = 625
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) 512 =========== - ##- - - - - * CPU3: 500 / 768 * 800 = 520
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) ## ## => total_energy = 1437
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) 341 -PP - - - - ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) PP ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) 170 -## - - - - ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) ## ## ## ##
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) ------------ -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) CPU0 CPU1 CPU2 CPU3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) From these calculations, the Case 1 has the lowest total energy. So CPU 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) is be the best candidate from an energy-efficiency standpoint.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) Big CPUs are generally more power hungry than the little ones and are thus used
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) mainly when a task doesn't fit the littles. However, little CPUs aren't always
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) necessarily more energy-efficient than big CPUs. For some systems, the high OPPs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) of the little CPUs can be less energy-efficient than the lowest OPPs of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) bigs, for example. So, if the little CPUs happen to have enough utilization at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) a specific point in time, a small task waking up at that moment could be better
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) of executing on the big side in order to save energy, even though it would fit
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) on the little side.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) And even in the case where all OPPs of the big CPUs are less energy-efficient
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) than those of the little, using the big CPUs for a small task might still, under
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) specific conditions, save energy. Indeed, placing a task on a little CPU can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) result in raising the OPP of the entire performance domain, and that will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) increase the cost of the tasks already running there. If the waking task is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) placed on a big CPU, its own execution cost might be higher than if it was
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) running on a little, but it won't impact the other tasks of the little CPUs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) which will keep running at a lower OPP. So, when considering the total energy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) consumed by CPUs, the extra cost of running that one task on a big core can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) smaller than the cost of raising the OPP on the little CPUs for all the other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) tasks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) The examples above would be nearly impossible to get right in a generic way, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) for all platforms, without knowing the cost of running at different OPPs on all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) CPUs of the system. Thanks to its EM-based design, EAS should cope with them
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) correctly without too many troubles. However, in order to ensure a minimal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) impact on throughput for high-utilization scenarios, EAS also implements another
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) mechanism called 'over-utilization'.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) 5. Over-utilization
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) -------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) From a general standpoint, the use-cases where EAS can help the most are those
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) involving a light/medium CPU utilization. Whenever long CPU-bound tasks are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) being run, they will require all of the available CPU capacity, and there isn't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) much that can be done by the scheduler to save energy without severly harming
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) throughput. In order to avoid hurting performance with EAS, CPUs are flagged as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) 'over-utilized' as soon as they are used at more than 80% of their compute
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) capacity. As long as no CPUs are over-utilized in a root domain, load balancing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) is disabled and EAS overridess the wake-up balancing code. EAS is likely to load
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) the most energy efficient CPUs of the system more than the others if that can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) done without harming throughput. So, the load-balancer is disabled to prevent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) it from breaking the energy-efficient task placement found by EAS. It is safe to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) do so when the system isn't overutilized since being below the 80% tipping point
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) implies that:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) a. there is some idle time on all CPUs, so the utilization signals used by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) EAS are likely to accurately represent the 'size' of the various tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) in the system;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) b. all tasks should already be provided with enough CPU capacity,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) regardless of their nice values;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) c. since there is spare capacity all tasks must be blocking/sleeping
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) regularly and balancing at wake-up is sufficient.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) As soon as one CPU goes above the 80% tipping point, at least one of the three
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) assumptions above becomes incorrect. In this scenario, the 'overutilized' flag
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) is raised for the entire root domain, EAS is disabled, and the load-balancer is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) re-enabled. By doing so, the scheduler falls back onto load-based algorithms for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) wake-up and load balance under CPU-bound conditions. This provides a better
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308) respect of the nice values of tasks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) Since the notion of overutilization largely relies on detecting whether or not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) there is some idle time in the system, the CPU capacity 'stolen' by higher
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) (than CFS) scheduling classes (as well as IRQ) must be taken into account. As
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) such, the detection of overutilization accounts for the capacity used not only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314) by CFS tasks, but also by the other scheduling classes and IRQ.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) 6. Dependencies and requirements for EAS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318) ----------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) Energy Aware Scheduling depends on the CPUs of the system having specific
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) hardware properties and on other features of the kernel being enabled. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) section lists these dependencies and provides hints as to how they can be met.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) 6.1 - Asymmetric CPU topology
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329) As mentioned in the introduction, EAS is only supported on platforms with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) asymmetric CPU topologies for now. This requirement is checked at run-time by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) looking for the presence of the SD_ASYM_CPUCAPACITY flag when the scheduling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) domains are built.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334) See Documentation/scheduler/sched-capacity.rst for requirements to be met for this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) flag to be set in the sched_domain hierarchy.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) Please note that EAS is not fundamentally incompatible with SMP, but no
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) significant savings on SMP platforms have been observed yet. This restriction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) could be amended in the future if proven otherwise.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) 6.2 - Energy Model presence
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) ^^^^^^^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) EAS uses the EM of a platform to estimate the impact of scheduling decisions on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) energy. So, your platform must provide power cost tables to the EM framework in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) order to make EAS start. To do so, please refer to documentation of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) independent EM framework in Documentation/power/energy-model.rst.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) Please also note that the scheduling domains need to be re-built after the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) EM has been registered in order to start EAS.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) 6.3 - Energy Model complexity
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) The task wake-up path is very latency-sensitive. When the EM of a platform is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) too complex (too many CPUs, too many performance domains, too many performance
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) states, ...), the cost of using it in the wake-up path can become prohibitive.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) The energy-aware wake-up algorithm has a complexity of:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) C = Nd * (Nc + Ns)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) with: Nd the number of performance domains; Nc the number of CPUs; and Ns the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) total number of OPPs (ex: for two perf. domains with 4 OPPs each, Ns = 8).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) A complexity check is performed at the root domain level, when scheduling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) domains are built. EAS will not start on a root domain if its C happens to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369) higher than the completely arbitrary EM_MAX_COMPLEXITY threshold (2048 at the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) time of writing).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) If you really want to use EAS but the complexity of your platform's Energy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373) Model is too high to be used with a single root domain, you're left with only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374) two possible options:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376) 1. split your system into separate, smaller, root domains using exclusive
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377) cpusets and enable EAS locally on each of them. This option has the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) benefit to work out of the box but the drawback of preventing load
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) balance between root domains, which can result in an unbalanced system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) overall;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381) 2. submit patches to reduce the complexity of the EAS wake-up algorithm,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) hence enabling it to cope with larger EMs in reasonable time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) 6.4 - Schedutil governor
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) ^^^^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) EAS tries to predict at which OPP will the CPUs be running in the close future
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) in order to estimate their energy consumption. To do so, it is assumed that OPPs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390) of CPUs follow their utilization.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392) Although it is very difficult to provide hard guarantees regarding the accuracy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) of this assumption in practice (because the hardware might not do what it is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) told to do, for example), schedutil as opposed to other CPUFreq governors at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) least _requests_ frequencies calculated using the utilization signals.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) Consequently, the only sane governor to use together with EAS is schedutil,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) because it is the only one providing some degree of consistency between
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) frequency requests and energy predictions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) Using EAS with any other governor than schedutil is not recommended.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) 6.5 Scale-invariant utilization signals
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406) In order to make accurate prediction across CPUs and for all performance
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) states, EAS needs frequency-invariant and CPU-invariant PELT signals. These can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) be obtained using the architecture-defined arch_scale{cpu,freq}_capacity()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409) callbacks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) Using EAS on a platform that doesn't implement these two callbacks is not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412) supported.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) 6.6 Multithreading (SMT)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416) ^^^^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) EAS in its current form is SMT unaware and is not able to leverage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) multithreaded hardware to save energy. EAS considers threads as independent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) CPUs, which can actually be counter-productive for both performance and energy.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) EAS on SMT is not supported.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags