Documentation/scheduler/schedutil.rst

7    All this assumes a linear relation between frequency and work capacity,
15 individual tasks to task-group slices to CPU runqueues. As the basis for this
31 Note that blocked tasks still contribute to the aggregates (task-group slices
32 and CPU runqueues), which reflects their expected contribution when they
36 reflects the time an entity spends on the CPU, while 'runnable' reflects the
38 two metrics are the same, but once there is contention for the CPU 'running'
39 will decrease to reflect the fraction of time each task spends on the CPU
45 Frequency / CPU Invariance
48 Because consuming the CPU for 50% at 1GHz is not the same as consuming the CPU
49 for 50% at 2GHz, nor is running 50% on a LITTLE CPU the same as running 50% on
50 a big CPU, we allow architectures to scale the time delta with two ratios, one
57   r_dvfs := -----
61 hardware counters (Intel APERF/MPERF, ARMv8.4-AMU) to provide us this ratio.
65   f_cur := ----- * P0
68 	     4C-turbo;	if available and turbo enabled
69   f_max := { 1C-turbo;	if turbo enabled
73   r_dvfs := min( 1, ----- )
79 CPU vs the highest performance level of any other CPU in the system.
84 of DVFS and CPU type. IOW. we can transfer and compare them between CPUs.
88  - kernel/sched/pelt.h:update_rq_clock_pelt()
89  - arch/x86/kernel/smpboot.c:"APERF/MPERF frequency ratio computation."
90  - Documentation/scheduler/sched-capacity.rst:"1. CPU Capacity + 2. Task utilization"
98 (DVFS) ramp-up after they are running again.
101 Impulse Response (IIR) EWMA with the 'running' value on dequeue -- when it is
128 The basis is the CPU runqueue's 'running' metric, which per the above it is
129 the frequency invariant utilization estimate of the CPU. From this we compute
142 XXX IO-wait: when the update is due to a task wakeup from IO-completion we
145 This frequency is then used to select a P-state/OPP or directly munged into a
152 interaction should be 'fast' and non-blocking. Schedutil supports
153 rate-limiting DVFS requests for when hardware interaction is slow and
162  - On low-load scenarios, where DVFS is most relevant, the 'running' numbers
165  - In saturated scenarios task movement will cause some transient dips,
166    suppose we have a CPU saturated with 4 tasks, then when we migrate a task
167    to an idle CPU, the old CPU will have a 'running' value of 0.75 while the
168    new CPU will gain 0.25. This is inevitable and time progression will
169    correct this. XXX do we still guarantee f_max due to no idle-time?
171  - Much of the above is about avoiding DVFS dips, and independent DVFS domains
172    having to re-learn / ramp-up when load shifts.