Lines Matching +full:performance +full:- +full:domains
6 ---------------
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]
38 performance [inst/s]
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
51 performance.
54 implications of its decisions rather than blindly applying energy-saving
60 for the scheduler to decide where a task should run (during wake-up), the EM
69 -----------------------
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
85 for further details about performance domains).
88 scheduling domains are built, or re-built. For each root domain (rd), the
89 scheduler maintains a singly linked list of all performance domains intersecting
90 the current rd->span. Each node in the list contains a pointer to a struct
93 The lists are attached to the root domains in order to cope with exclusive
95 necessarily match those of performance domains, the lists of different root
96 domains can contain duplicate elements.
99 Let us consider a platform with 12 CPUs, split in 3 performance domains
103 PDs: |--pd0--|--pd4--|---pd8---|
104 RDs: |----rd1----|-----rd2-----|
107 exclusive cpusets, hence creating two independent root domains, each
108 containing 6 CPUs. The two root domains are denoted rd1 and rd2 in the
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
136 each performance domain since it is the one which will allow us to keep the
145 which computes the expected energy consumption of each performance domain for
148 An example of energy-optimized task placement decision is detailed below.
151 Let us consider a (fake) platform with 2 independent performance domains
159 below. CPUs 0-3 have a util_avg of 400, 100, 600 and 500 respectively
160 Each performance domain has three Operating Performance Points (OPPs).
166 1024 - - - - - - - Energy Model
167 +-----------+-------------+
169 768 ============= +-----+-----+------+------+
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): ##
185 maximum spare capacity in the two performance domains. In this example,
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
258 And even in the case where all OPPs of the big CPUs are less energy-efficient
261 result in raising the OPP of the entire performance domain, and that will
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
285 throughput. In order to avoid hurting performance with EAS, CPUs are flagged as
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
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
318 ----------------------------------------
325 6.1 - Asymmetric CPU topology
330 asymmetric CPU topologies for now. This requirement is checked at run-time by
332 domains are built.
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
388 In order to make accurate prediction across CPUs and for all performance
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.