Lines Matching +full:max +full:- +full:frequency
1 .. SPDX-License-Identifier: GPL-2.0
18 used, util clamp will influence the CPU frequency selection as well.
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
65 1. The big cores are free to run top-app tasks immediately. top-app
89 higher frequency required for the tasks to finish their work in time. Setting
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
111 helps picking what frequency to request instead of schedutil always requesting
112 MAX for all RT tasks.
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
132 frequency selection as well as task placement to be most effective. Both of
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
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.
264 2.2. Max aggregation
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
298 -----------------------------
311 :ref:`Section 3 <uclamp-interfaces>` discusses the interfaces and will expand
328 ----------
333 Just like other cgroup interfaces, you can use 'max' instead of 100.
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 ---------------------
377 * cpu.uclamp.max
382 * cpu.uclamp.min is a protection as described in :ref:`section 3-3 of cgroup
383 v2 documentation <cgroupv2-protections-distributor>`.
388 In a cgroup hierarchy, effective cpu.uclamp.min is the max of (child,
391 * cpu.uclamp.max is a limit as described in :ref:`section 3-2 of cgroup v2
392 documentation <cgroupv2-limits-distributor>`.
394 If a task uclamp_max value is higher than cpu.uclamp.max, then the task will
395 inherit the cgroup cpu.uclamp.max value.
397 In a cgroup hierarchy, effective cpu.uclamp.max is the min of (child,
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
436 Note that cgroup interfaces allows cpu.uclamp.max value to be lower than
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 -------------------------------------
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
548 to deliver the desired user experience. The right frequency it requires at
561 which will imply both task placement and frequency selection**.
564 -------------------------
571 -------------------
577 This is not unique to uclamp as one can achieve the same by reducing max
578 frequency of the cpufreq governor. It can be considered a more convenient
581 4.4. Per-app performance restriction
582 ------------------------------------
584 Middleware/Utility can provide the user an option to set UCLAMP_MIN/MAX for an
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
614 then due to max aggregation the rq will be allowed to reach max performance
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
689 p1->util_avg = 200
690 p1->uclamp[UCLAMP_MAX] = 1024
692 then the effective UCLAMP_MAX for the CPU will be 1024 according to max
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.