Lines Matching +full:run +full:- +full:time
1 .. SPDX-License-Identifier: GPL-2.0
23 system run at a certain performance point.
57 foreground, top-app, etc. Util clamp can be used to constrain how much
59 can run at. This constraint helps reserve resources for important tasks, like
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
68 2. They don't run on a power hungry core and drain battery even if they
85 On the other hand, a busy task for instance that requires to run at maximum
88 mobile devices where frames will drop due to slow response time to select the
89 higher frequency required for the tasks to finish their work in time. Setting
102 In the SCHED_FIFO/RR case, uclamp gives the option to run RT tasks at any
103 performance point rather than being tied to MAX frequency all the time. Which
104 can be useful on general purpose systems that run on battery powered devices.
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.
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
126 inspect PELT signals at any point of time you should continue to see them as
128 and the scheduler needs to select a suitable CPU for it to run on.
131 performance point for a task to run on, it must be able to influence the
138 a task requests to run at UTIL_MIN = 512, then the util signal of the rq needs
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
162 moment of time it needs to take a decision.
182 .. _uclamp-buckets:
185 ------------
195 +-----------+-----------+-----------+---- ----+-----------+
197 +-----------+-----------+-----------+---- ----+-----------+
199 +- p0 +- p3 +- p4
201 +- p1 +- p5
203 +- p2
212 into N buckets where N is configured at compile time by setting
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
298 -----------------------------
311 :ref:`Section 3 <uclamp-interfaces>` discusses the interfaces and will expand
328 ----------
335 .. _uclamp-interfaces:
341 -----------------------
345 * sched_util_min: requests the minimum performance point the system should run
347 * sched_util_max: requests the maximum performance point the system should run
354 attr->sched_util_min = 40% * 1024;
355 attr->sched_util_max = 80% * 1024;
358 starts at 40% performance level**. If the task runs for a long enough time so
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 --------------------------
462 [0:512]. This means is that no task can run above 512, which implies that all
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
488 That is, by default they're boosted to run at the maximum performance point of
496 p_rt->uclamp[UCLAMP_MIN] = 1024
497 p_rt->uclamp[UCLAMP_MAX] = 1024
499 That is by default they're boosted to run at the maximum performance point of
505 .. _sched-util-clamp-min-rt-default:
508 -------------------------------------
515 performance point all the time.
543 4.1. Boost important and DVFS-latency-sensitive tasks
544 -----------------------------------------------------
547 wakes up. However, it requires to finish its work within a specific time window
552 This task can increase its UCLAMP_MIN value every time it misses the deadline
557 On heterogeneous systems, it might be important for this task to run on
564 -------------------------
571 -------------------
581 4.4. Per-app performance restriction
582 ------------------------------------
585 app every time it is executed to guarantee a minimum performance point and/or
597 .. _uclamp-capping-fail:
600 ---------------------------------------------------------------------
602 If task p0 is capped to run at 512:
606 p0->uclamp[UCLAMP_MAX] = 512
608 and it shares the rq with p1 which is free to run at any performance point:
612 p1->uclamp[UCLAMP_MAX] = 1024
619 rq->uclamp[UCLAMP_MAX] = max(512, 1024) = 1024
626 from the rq although p1, which is allowed to run at any performance point,
627 doesn't actually need to run at that frequency.
630 ------------------------------------------------
633 there's always some idle time on the CPU. But with UCLAMP_MAX, this frequency
634 increase will be prevented which can lead to no idle time in some
635 circumstances. When there's no idle time, a task will stuck in a busy loop,
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
650 since it designates the shortest computational time to finish the task's
655 rq->uclamp[UCLAMP_MAX] = 0
663 which indicates the CPU will still see idle time since 900 is < 1024. The
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
678 which is higher than 1024 and indicates that the CPU has no idle time. When
683 p0->util_avg = 1024
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
708 p0->util_avg = 300
709 p1->util_avg = 200
711 rq->util_avg = 500
713 and run somewhere near mid performance point of that CPU, not the Fmax we get.
715 5.3. Schedutil response time issues
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
729 limitations will prevent it from getting what it wants in the time scale it