Lines Matching +full:core +full:- +full:pwr +full:- +full:good +full:- +full:time
6 ---------------
15 Before going any further, please note that at the time of writing::
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 -----------------------
76 tasks and CPUs computed by the Per-Entity Load Tracking (PELT) mechanism. Thanks
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
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
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 ------------ -------------
230 1024 - - - - - - -
236 512 =========== - ##- - - - - * CPU3: 500 / 768 * 800 = 520
238 341 -PP - - - - ## ##
240 170 -## - - - - ## ##
242 ------------ -------------
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
266 consumed by CPUs, the extra cost of running that one task on a big core can be
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
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
301 regularly and balancing at wake-up is sufficient.
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
356 in milli-Watts or in an 'abstract scale'.
359 6.3 - Energy Model complexity
367 6.4 - Schedutil governor
385 6.5 Scale-invariant utilization signals
389 states, EAS needs frequency-invariant and CPU-invariant PELT signals. These can
390 be obtained using the architecture-defined arch_scale{cpu,freq}_capacity()
402 CPUs, which can actually be counter-productive for both performance and energy.