Lines Matching +full:fast +full:- +full:dvfs

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
51 Dynamic Voltage and Frequency Scaling (DVFS) ratio and one microarch ratio.
53 For simple DVFS architectures (where software is in full control) we trivially
57   r_dvfs := -----
60 For more dynamic systems where the hardware is in control of DVFS we use
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, ----- )
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
120 Schedutil / DVFS
125 DVFS state.
141 XXX IO-wait: when the update is due to a task wakeup from IO-completion we
144 This frequency is then used to select a P-state/OPP or directly munged into a
150 Because these callbacks are directly from the scheduler, the DVFS hardware
151 interaction should be 'fast' and non-blocking. Schedutil supports
152 rate-limiting DVFS requests for when hardware interaction is slow and
161  - On low-load scenarios, where DVFS is most relevant, the 'running' numbers
164  - In saturated scenarios task movement will cause some transient dips,
168    correct this. XXX do we still guarantee f_max due to no idle-time?
170  - Much of the above is about avoiding DVFS dips, and independent DVFS domains
171    having to re-learn / ramp-up when load shifts.