From: Zhe Liu <liuzhe1@kylinos.cn>
To: mkoutny@suse.com
Cc: bsegall@google.com, cgroups@vger.kernel.org, corbet@lwn.net,
dietmar.eggemann@arm.com, hannes@cmpxchg.org,
juri.lelli@redhat.com, kprateek.nayak@amd.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, liuzhe1@kylinos.cn,
mgorman@suse.de, mingo@redhat.com, peterz@infradead.org,
rostedt@goodmis.org, skhan@linuxfoundation.org, tj@kernel.org,
vincent.guittot@linaro.org, vschneid@redhat.com
Subject: [PATCH v2 3/3] Documentation: describe CPU quota and burst ordering
Date: Fri, 4 Sep 2026 14:20:13 +0800 [thread overview]
Message-ID: <20260904062013.504236-4-liuzhe1@kylinos.cn> (raw)
In-Reply-To: <20260904062013.504236-1-liuzhe1@kylinos.cn>
Document the independent quota and burst configuration and the runtime
burst clamp.
Signed-off-by: Zhe Liu <liuzhe1@kylinos.cn>
---
Documentation/admin-guide/cgroup-v2.rst | 5 ++++-
Documentation/scheduler/sched-bwc.rst | 21 ++++++++++++---------
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 7c2a8ed80071..57253c2c1819 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1229,7 +1229,10 @@ will be referred to. All time durations are in microseconds.
A read-write single value file which exists on non-root
cgroups. The default is "0".
- The burst in the range [0, $MAX].
+ The burst in the range [0, $MAX]. The configured value is retained when
+ the quota changes and may be larger than the current quota. During CFS
+ runtime refill, the effective burst is limited to the current quota.
+ The quota and burst files can therefore be written in either order.
This file affects only processes under the fair-class scheduler.
diff --git a/Documentation/scheduler/sched-bwc.rst b/Documentation/scheduler/sched-bwc.rst
index e881a945c188..08a54ee84da2 100644
--- a/Documentation/scheduler/sched-bwc.rst
+++ b/Documentation/scheduler/sched-bwc.rst
@@ -90,20 +90,22 @@ bandwidth restriction in place, such a group is described as an unconstrained
bandwidth group. This represents the traditional work-conserving behavior for
CFS.
-Writing any (valid) positive value(s) no smaller than cpu.cfs_burst_us will
-enact the specified bandwidth limit. The minimum quota allowed for the quota or
-period is 1ms. There is also an upper bound on the period length of 1s.
-Additional restrictions exist when bandwidth limits are used in a hierarchical
-fashion, these are explained in more detail below.
+Writing any valid quota value will enact the specified bandwidth limit. The
+minimum quota allowed for the quota or period is 1ms. There is also an upper
+bound on the period length of 1s. Additional restrictions exist when bandwidth
+limits are used in a hierarchical fashion, these are explained in more detail
+below.
Writing any negative value to cpu.cfs_quota_us will remove the bandwidth limit
and return the group to an unconstrained state once more.
A value of 0 for cpu.cfs_burst_us indicates that the group can not accumulate
any unused bandwidth. It makes the traditional bandwidth control behavior for
-CFS unchanged. Writing any (valid) positive value(s) no larger than
-cpu.cfs_quota_us into cpu.cfs_burst_us will enact the cap on unused bandwidth
-accumulation.
+CFS unchanged. A valid positive value written to cpu.cfs_burst_us is retained
+when the quota changes. If it is larger than the current quota, CFS limits the
+effective burst during runtime refill to the current quota.
+
+The quota and burst files can be updated in either order.
Any updates to a group's bandwidth specification will result in it becoming
unthrottled if it is in a constrained state.
@@ -243,4 +245,5 @@ Examples
# echo 50000 > cpu.cfs_period_us /* period = 50ms */
# echo 10000 > cpu.cfs_burst_us /* burst = 10ms */
- Larger buffer setting (no larger than quota) allows greater burst capacity.
+ A larger buffer setting allows greater burst capacity. If the configured
+ burst is larger than the quota, the effective burst is limited to the quota.
--
2.25.1
next prev parent reply other threads:[~2026-09-04 6:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 3:32 [PATCH 0/2] sched/fair: Reset incompatible burst on quota change Zhe Liu
2026-08-20 3:32 ` [PATCH 1/2] " Zhe Liu
2026-08-20 11:43 ` Michal Koutný
2026-08-26 3:00 ` Zhe Liu
2026-09-04 6:20 ` [PATCH v2 0/3] sched/fair: remove quota/burst write-order dependency Zhe Liu
2026-09-04 6:20 ` [PATCH v2 1/3] sched/fair: Remove the write-order dependency between cpu.max and cpu.max.burst Zhe Liu
2026-09-04 9:21 ` Tao Cui
2026-09-07 14:06 ` Michal Koutný
2026-09-04 6:20 ` [PATCH v2 2/3] selftests: cgroup: Test CPU quota and burst write order Zhe Liu
2026-09-04 6:20 ` Zhe Liu [this message]
2026-08-20 3:32 ` [PATCH 2/2] Documentation: describe burst reset on quota changes Zhe Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260904062013.504236-4-liuzhe1@kylinos.cn \
--to=liuzhe1@kylinos.cn \
--cc=bsegall@google.com \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=dietmar.eggemann@arm.com \
--cc=hannes@cmpxchg.org \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=mkoutny@suse.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=skhan@linuxfoundation.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®