Lines Matching +full:power +full:- +full:up +full:- +full:frequency
1 .. SPDX-License-Identifier: GPL-2.0
18 used, util clamp will influence the CPU frequency selection as well.
45 dropped. It can also dynamically 'prime' up these tasks if it knows in the
57 foreground, top-app, etc. Util clamp can be used to constrain how much
60 the ones belonging to the currently active app (top-app group). Beside this
61 helps in limiting how much power they consume. This can be more obvious in
65 1. The big cores are free to run top-app tasks immediately. top-app
68 2. They don't run on a power hungry core and drain battery even if they
82 Another use case is to help with **overcoming the ramp up latency inherit in
89 higher frequency required for the tasks to finish their work in time. Setting
98 the device doesn't heat up to the point where it will throttle.
103 performance point rather than being tied to MAX frequency all the time. Which
106 Note that by design RT tasks don't have per-task PELT signal and must always
107 run at a constant frequency to combat undeterministic DVFS rampup delays.
109 Note that using schedutil always implies a single delay to modify the frequency
110 when an RT task wakes up. This cost is unchanged by using uclamp. Uclamp only
111 helps picking what frequency to request instead of schedutil always requesting
114 See :ref:`section 3.4 <uclamp-default-values>` for default values and
115 :ref:`3.4.1 <sched-util-clamp-min-rt-default>` on how to change RT tasks
127 they are intact. Clamping happens only when needed, e.g: when a task wakes up
132 frequency selection as well as task placement to be most effective. Both of
136 When a task wakes up on an rq, the utilization signal of the rq will be
150 task on the rq to only a subset of tasks on the top-most bucket.
157 uclamp value of the rq. See :ref:`section 2.1 <uclamp-buckets>` for details on
167 When a task wakes up, the scheduler will look at the current effective uclamp
169 to be enqueued there. Favoring the rq that will end up with the most energy
172 Similarly in schedutil, when it needs to make a frequency update it will look
174 of tasks currently enqueued there and select the appropriate frequency that
182 .. _uclamp-buckets:
185 ------------
195 +-----------+-----------+-----------+---- ----+-----------+
197 +-----------+-----------+-----------+---- ----+-----------+
199 +- p0 +- p3 +- p4
201 +- p1 +- p5
203 +- p2
234 p->uclamp[UCLAMP_MIN] = 300
235 p->uclamp[UCLAMP_MAX] = 1024
249 rq->uclamp[UCLAMP_MIN] = max(rq->uclamp[UCLAMP_MIN], p->uclamp[UCLAMP_MIN])
257 rq->uclamp[UCLAMP_MIN] = search_top_bucket_for_highest_value()
261 See :ref:`section 3.4 <uclamp-default-values>` for details on default values.
265 --------------------
279 p0->uclamp[UCLAMP_MIN] = 300
280 p0->uclamp[UCLAMP_MAX] = 900
282 p1->uclamp[UCLAMP_MIN] = 500
283 p1->uclamp[UCLAMP_MAX] = 500
290 rq->uclamp[UCLAMP_MIN] = max(300, 500) = 500
291 rq->uclamp[UCLAMP_MAX] = max(900, 500) = 900
293 As we shall see in :ref:`section 5.1 <uclamp-capping-fail>`, this max
295 particular for UCLAMP_MAX hint when user space would like to save power.
298 -----------------------------
311 :ref:`Section 3 <uclamp-interfaces>` discusses the interfaces and will expand
328 ----------
335 .. _uclamp-interfaces:
341 -----------------------
354 attr->sched_util_min = 40% * 1024;
355 attr->sched_util_max = 80% * 1024;
362 The special value -1 is used to reset the uclamp settings to the system
365 Note that resetting the uclamp value to system default using -1 is not the same
372 ---------------------
382 * cpu.uclamp.min is a protection as described in :ref:`section 3-3 of cgroup
383 v2 documentation <cgroupv2-protections-distributor>`.
391 * cpu.uclamp.max is a limit as described in :ref:`section 3-2 of cgroup v2
392 documentation <cgroupv2-limits-distributor>`.
404 p0->uclamp[UCLAMP_MIN] = // system default;
405 p0->uclamp[UCLAMP_MAX] = // system default;
407 p1->uclamp[UCLAMP_MIN] = 40% * 1024;
408 p1->uclamp[UCLAMP_MAX] = 50% * 1024;
410 cgroup0->cpu.uclamp.min = 20% * 1024;
411 cgroup0->cpu.uclamp.max = 60% * 1024;
413 cgroup1->cpu.uclamp.min = 60% * 1024;
414 cgroup1->cpu.uclamp.max = 100% * 1024;
420 p0->uclamp[UCLAMP_MIN] = cgroup0->cpu.uclamp.min = 20% * 1024;
421 p0->uclamp[UCLAMP_MAX] = cgroup0->cpu.uclamp.max = 60% * 1024;
423 p1->uclamp[UCLAMP_MIN] = 40% * 1024; // intact
424 p1->uclamp[UCLAMP_MAX] = 50% * 1024; // intact
430 p0->uclamp[UCLAMP_MIN] = cgroup1->cpu.uclamp.min = 60% * 1024;
431 p0->uclamp[UCLAMP_MAX] = cgroup1->cpu.uclamp.max = 100% * 1024;
433 p1->uclamp[UCLAMP_MIN] = cgroup1->cpu.uclamp.min = 60% * 1024;
434 p1->uclamp[UCLAMP_MAX] = 50% * 1024; // intact
440 ---------------------
443 --------------------------
451 they won't be satisfied until it is more than p->uclamp[UCLAMP_MIN].
456 --------------------------
472 won't be satisfied until it is more than p->uclamp[UCLAMP_MAX].
476 .. _uclamp-default-values:
479 -------------------
485 p_fair->uclamp[UCLAMP_MIN] = 0
486 p_fair->uclamp[UCLAMP_MAX] = 1024
496 p_rt->uclamp[UCLAMP_MIN] = 1024
497 p_rt->uclamp[UCLAMP_MAX] = 1024
505 .. _sched-util-clamp-min-rt-default:
508 -------------------------------------
514 address the system requirement without burning power running at maximum
518 to ensure they are performance and power aware. Ideally this knob should be set
525 Util clamp promotes the concept of user space assisted power and performance
528 better decision about task placement and frequency selection.
543 4.1. Boost important and DVFS-latency-sensitive tasks
544 -----------------------------------------------------
546 A GUI task might not be busy to warrant driving the frequency high when it
547 wakes up. However, it requires to finish its work within a specific time window
548 to deliver the desired user experience. The right frequency it requires at
553 to ensure on next wake up it runs at a higher performance point. It should try
561 which will imply both task placement and frequency selection**.
564 -------------------------
568 could end up being busy and consume unnecessary system resources on the system.
571 -------------------
578 frequency of the cpufreq governor. It can be considered a more convenient
581 4.4. Per-app performance restriction
582 ------------------------------------
586 limit it from draining system power at the cost of reduced performance for
589 If you want to prevent your laptop from heating up while on the go from
590 compiling the kernel and happy to sacrifice performance to save power, but
597 .. _uclamp-capping-fail:
599 5.1. Capping frequency with uclamp_max fails under certain conditions
600 ---------------------------------------------------------------------
606 p0->uclamp[UCLAMP_MAX] = 512
612 p1->uclamp[UCLAMP_MAX] = 1024
619 rq->uclamp[UCLAMP_MAX] = max(512, 1024) = 1024
621 Assuming both p0 and p1 have UCLAMP_MIN = 0, then the frequency selection for
625 both are running at the same rq, p1 will cause the frequency capping to be left
627 doesn't actually need to run at that frequency.
630 ------------------------------------------------
632 PELT assumes that frequency will always increase as the signals grow to ensure
633 there's always some idle time on the CPU. But with UCLAMP_MAX, this frequency
638 Combing with issue described below, this can lead to unwanted frequency spikes
645 p0->util_avg = 300
646 p0->uclamp[UCLAMP_MAX] = 0
648 wakes up on an idle CPU, then it will run at min frequency (Fmin) this
649 CPU is capable of. The max CPU frequency (Fmax) matters here as well,
655 rq->uclamp[UCLAMP_MAX] = 0
665 long as there's idle time, p->util_avg updates will be off by a some margin,
670 p0->util_avg = 300 + small_error
683 p0->util_avg = 1024
685 If task p1 wakes up on this CPU, which have:
689 p1->util_avg = 200
690 p1->uclamp[UCLAMP_MAX] = 1024
694 severely, then the rq->util_avg will be:
698 p0->util_avg = 1024
699 p1->util_avg = 200
701 rq->util_avg = 1024
702 rq->uclamp[UCLAMP_MAX] = 1024
704 Hence lead to a frequency spike since if p0 wasn't throttled we should get:
708 p0->util_avg = 300
709 p1->util_avg = 200
711 rq->util_avg = 500
716 -----------------------------------
720 1. Hardware takes non-zero time to respond to any frequency change
722 2. Non fast-switch systems require a worker deadline thread to wake up
723 and perform the frequency change, which adds measurable overhead.
728 performance point when it wakes up and starts running, then all these
733 prevalent as we no longer gradually ramp up or down. We could easily be
734 jumping between frequencies depending on the order tasks wake up, and their