Lines Matching +full:cpu +full:- +full:pwr +full:- +full:good +full:- +full:time
6 ---------------
10 Energy Model (EM) of the CPUs to select an energy efficient CPU for each task,
15 Before going any further, please note that at the time of writing::
17 /!\ EAS does not support platforms with symmetric CPU topologies /!\
19 EAS operates only on heterogeneous CPU topologies (such as Arm big.LITTLE)
25 please refer to its documentation (see Documentation/power/energy-model.rst).
29 -----------------------------
32 - energy = [joule] (resource like a battery on powered devices)
33 - power = energy/time = [joule/second] = [watt]
39 --------------------
45 -----------
48 while still getting 'good' performance. It is essentially an alternative
49 optimization objective to the current performance-only objective for the
50 scheduler. This alternative considers two objectives: energy-efficiency and
54 implications of its decisions rather than blindly applying energy-saving
56 time, the EM must be as simple as possible to minimize the scheduler latency
59 In short, EAS changes the way CFS tasks are assigned to CPUs. When it is time
60 for the scheduler to decide where a task should run (during wake-up), the EM
61 is used to break the tie between several good CPU candidates and pick the one
69 -----------------------
72 differentiate CPUs with different computing throughput. The 'capacity' of a CPU
74 frequency compared to the most capable CPU of the system. Capacity values are
76 tasks and CPUs computed by the Per-Entity Load Tracking (PELT) mechanism. Thanks
78 task/CPU is, and to take this into consideration when evaluating performance vs
79 energy trade-offs. The capacity of CPUs is provided via arch-specific code
84 per 'performance domain' in the system (see Documentation/power/energy-model.rst
88 scheduling domains are built, or re-built. For each root domain (rd), the
90 the current rd->span. Each node in the list contains a pointer to a struct
103 PDs: |--pd0--|--pd4--|---pd8---|
104 RDs: |----rd1----|-----rd2-----|
110 present in the linked list '->pd' attached to each of them:
112 * rd1->pd: pd0 -> pd4
113 * rd2->pd: pd4 -> pd8
128 4. Energy-Aware task placement
129 ------------------------------
131 EAS overrides the CFS task wake-up balancing code. It uses the EM of the
132 platform and the PELT signals to choose an energy-efficient target CPU during
133 wake-up balance. When EAS is enabled, select_task_rq_fair() calls
135 for the CPU with the highest spare capacity (CPU capacity - CPU utilization) in
138 save energy compared to leaving it on prev_cpu, i.e. the CPU where the task ran
148 An example of energy-optimized task placement decision is detailed below.
159 below. CPUs 0-3 have a util_avg of 400, 100, 600 and 500 respectively
161 The CPU capacity and power cost associated with each OPP is listed in
165 CPU util.
166 1024 - - - - - - - Energy Model
167 +-----------+-------------+
169 768 ============= +-----+-----+------+------+
170 | Cap | Pwr | Cap | Pwr |
171 +-----+-----+------+------+
172 512 =========== - ##- - - - - | 170 | 50 | 512 | 400 |
174 341 -PP - - - - ## ## | 512 | 300 | 1024 | 1700 |
175 PP ## ## +-----+-----+------+------+
176 170 -## - - - - ## ##
178 ------------ -------------
181 Current OPP: ===== Other OPP: - - - util_avg (100 each): ##
194 1024 - - - - - - -
200 512 - - - - - - - ##- - - - - * CPU3: 500 / 768 * 800 = 520
204 170 -## - - PP- ## ##
206 ------------ -------------
212 1024 - - - - - - -
218 512 - - - - - - - ##- - -PP - * CPU3: 700 / 768 * 800 = 729
222 170 -## - - - - ## ##
224 ------------ -------------
228 **Case 3. P stays on prev_cpu / CPU 0**::
230 1024 - - - - - - -
236 512 =========== - ##- - - - - * CPU3: 500 / 768 * 800 = 520
238 341 -PP - - - - ## ##
240 170 -## - - - - ## ##
242 ------------ -------------
246 From these calculations, the Case 1 has the lowest total energy. So CPU 1
247 is be the best candidate from an energy-efficiency standpoint.
251 necessarily more energy-efficient than big CPUs. For some systems, the high OPPs
252 of the little CPUs can be less energy-efficient than the lowest OPPs of the
254 a specific point in time, a small task waking up at that moment could be better
258 And even in the case where all OPPs of the big CPUs are less energy-efficient
260 specific conditions, save energy. Indeed, placing a task on a little CPU can
263 placed on a big CPU, its own execution cost might be higher than if it was
272 CPUs of the system. Thanks to its EM-based design, EAS should cope with them
274 impact on throughput for high-utilization scenarios, EAS also implements another
275 mechanism called 'over-utilization'.
278 5. Over-utilization
279 -------------------
281 From a general standpoint, the use-cases where EAS can help the most are those
282 involving a light/medium CPU utilization. Whenever long CPU-bound tasks are
283 being run, they will require all of the available CPU capacity, and there isn't
286 'over-utilized' as soon as they are used at more than 80% of their compute
287 capacity. As long as no CPUs are over-utilized in a root domain, load balancing
288 is disabled and EAS overridess the wake-up balancing code. EAS is likely to load
290 done without harming throughput. So, the load-balancer is disabled to prevent
291 it from breaking the energy-efficient task placement found by EAS. It is safe to
295 a. there is some idle time on all CPUs, so the utilization signals used by
298 b. all tasks should already be provided with enough CPU capacity,
301 regularly and balancing at wake-up is sufficient.
303 As soon as one CPU goes above the 80% tipping point, at least one of the three
305 is raised for the entire root domain, EAS is disabled, and the load-balancer is
306 re-enabled. By doing so, the scheduler falls back onto load-based algorithms for
307 wake-up and load balance under CPU-bound conditions. This provides a better
311 there is some idle time in the system, the CPU capacity 'stolen' by higher
318 ----------------------------------------
325 6.1 - Asymmetric CPU topology
330 asymmetric CPU topologies for now. This requirement is checked at run-time by
334 See Documentation/scheduler/sched-capacity.rst for requirements to be met for this
342 6.2 - Energy Model presence
348 independent EM framework in Documentation/power/energy-model.rst.
350 Please also note that the scheduling domains need to be re-built after the
354 6.3 - Energy Model complexity
357 The task wake-up path is very latency-sensitive. When the EM of a platform is
359 states, ...), the cost of using it in the wake-up path can become prohibitive.
360 The energy-aware wake-up algorithm has a complexity of:
370 time of writing).
381 2. submit patches to reduce the complexity of the EAS wake-up algorithm,
382 hence enabling it to cope with larger EMs in reasonable time.
385 6.4 - Schedutil governor
403 6.5 Scale-invariant utilization signals
407 states, EAS needs frequency-invariant and CPU-invariant PELT signals. These can
408 be obtained using the architecture-defined arch_scale{cpu,freq}_capacity()
420 CPUs, which can actually be counter-productive for both performance and energy.