Lines Matching +full:1 +full:- +full:cpu
6 This document only discusses CPU bandwidth control for SCHED_NORMAL.
7 The SCHED_RT case is covered in Documentation/scheduler/sched-rt-group.rst
10 specification of the maximum CPU bandwidth available to a group or hierarchy.
14 microseconds of CPU time. That quota is assigned to per-cpu run queues in
22 is transferred to cpu-local "silos" on a demand basis. The amount transferred
26 -------------
30 Traditional (UP-EDF) bandwidth control is something like:
32 (U = \Sum u_i) <= 1
35 stable. After all, if U were > 1, then for every second of walltime,
64 there many cgroups or CPU is under utilized, the interference is
66 https://lore.kernel.org/lkml/5371BD36-55AE-4F71-B9D7-B86DC32E3D2B@linux.alibaba.com/
69 ----------
70 Quota, period and burst are managed within the cpu subsystem via cgroupfs.
75 :ref:`Documentation/admin-guide/cgroup-v2.rst <cgroup-v2-cpu>`.
77 - cpu.cfs_quota_us: run-time replenished within a period (in microseconds)
78 - cpu.cfs_period_us: the length of a period (in microseconds)
79 - cpu.stat: exports throttling statistics [explained further below]
80 - cpu.cfs_burst_us: the maximum accumulated run-time (in microseconds)
84 cpu.cfs_period_us=100ms
85 cpu.cfs_quota_us=-1
86 cpu.cfs_burst_us=0
88 A value of -1 for cpu.cfs_quota_us indicates that the group does not have any
90 bandwidth group. This represents the traditional work-conserving behavior for
93 Writing any (valid) positive value(s) no smaller than cpu.cfs_burst_us will
95 period is 1ms. There is also an upper bound on the period length of 1s.
99 Writing any negative value to cpu.cfs_quota_us will remove the bandwidth limit
102 A value of 0 for cpu.cfs_burst_us indicates that the group can not accumulate
105 cpu.cfs_quota_us into cpu.cfs_burst_us will enact the cap on unused bandwidth
112 --------------------
113 For efficiency run-time is transferred between the global pool and CPU local
123 for more fine-grained consumption.
126 ----------
127 A group's bandwidth statistics are exported via 5 fields in cpu.stat.
129 cpu.stat:
131 - nr_periods: Number of enforcement intervals that have elapsed.
132 - nr_throttled: Number of times the group has been throttled/limited.
133 - throttled_time: The total time duration (in nanoseconds) for which entities
135 - nr_bursts: Number of periods burst occurs.
136 - burst_time: Cumulative wall-time (in nanoseconds) that any CPUs has used
139 This interface is read-only.
142 ---------------------------
144 attainable, that is: max(c_i) <= C. However, over-subscription in the
145 aggregate case is explicitly allowed to enable work-conserving semantics
162 ---------------------------
163 Once a slice is assigned to a cpu it does not expire. However all but 1ms of
164 the slice may be returned to the global pool if all threads on that cpu become
169 The fact that cpu-local slices do not expire results in some interesting corner
172 For cgroup cpu constrained applications that are cpu limited this is a
174 quota as well as the entirety of each cpu-local slice in each period. As a
178 For highly-threaded, non-cpu bound applications this non-expiration nuance
180 unused slice on each cpu that the task group is running on (typically at most
181 1ms per cpu or as defined by min_cfs_rq_runtime). This slight burst only
182 applies if quota had been assigned to a cpu and then not fully used or returned
186 also limits the burst ability to no more than 1ms per cpu. This provides
190 quota amounts of cpu. Another way to say this, is that by allowing the unused
192 possibility of wastefully expiring quota on cpu-local silos that don't need a
193 full slice's amount of cpu time.
195 The interaction between cpu-bound and non-cpu-bound-interactive applications
197 gave each of these applications half of a cpu-core and they both got scheduled
198 on the same CPU it is theoretically possible that the non-cpu bound application
199 will use up to 1ms additional quota in some periods, thereby preventing the
200 cpu-bound application from fully using its quota by that same amount. In these
201 instances it will be up to the CFS algorithm (see sched-design-CFS.rst) to
207 --------
208 1. Limit a group to 1 CPU worth of runtime::
211 1 CPU worth of runtime every 250ms.
213 # echo 250000 > cpu.cfs_quota_us /* quota = 250ms */
214 # echo 250000 > cpu.cfs_period_us /* period = 250ms */
216 2. Limit a group to 2 CPUs worth of runtime on a multi-CPU machine
221 # echo 1000000 > cpu.cfs_quota_us /* quota = 1000ms */
222 # echo 500000 > cpu.cfs_period_us /* period = 500ms */
226 3. Limit a group to 20% of 1 CPU.
228 With 50ms period, 10ms quota will be equivalent to 20% of 1 CPU::
230 # echo 10000 > cpu.cfs_quota_us /* quota = 10ms */
231 # echo 50000 > cpu.cfs_period_us /* period = 50ms */
236 4. Limit a group to 40% of 1 CPU, and allow accumulate up to 20% of 1 CPU
239 With 50ms period, 20ms quota will be equivalent to 40% of 1 CPU.
240 And 10ms burst will be equivalent to 20% of 1 CPU::
242 # echo 20000 > cpu.cfs_quota_us /* quota = 20ms */
243 # echo 50000 > cpu.cfs_period_us /* period = 50ms */
244 # echo 10000 > cpu.cfs_burst_us /* burst = 10ms */