From: Zhe Liu <liuzhe1@kylinos.cn>
To: tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com,
corbet@lwn.net, mingo@redhat.com, peterz@infradead.org,
juri.lelli@redhat.com, vincent.guittot@linaro.org
Cc: skhan@linuxfoundation.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, kprateek.nayak@amd.com,
cgroups@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
Zhe Liu <liuzhe1@kylinos.cn>
Subject: [PATCH 2/2] Documentation: describe burst reset on quota changes
Date: Thu, 20 Aug 2026 11:32:18 +0800 [thread overview]
Message-ID: <20260820033218.214259-3-liuzhe1@kylinos.cn> (raw)
In-Reply-To: <20260820033218.214259-1-liuzhe1@kylinos.cn>
Document that an incompatible burst is reset when a finite quota is
written through the cgroup v1 or cgroup v2 CPU bandwidth interface, while
compatible bursts and unlimited quota updates preserve the existing value.
Signed-off-by: Zhe Liu <liuzhe1@kylinos.cn>
---
Documentation/admin-guide/cgroup-v2.rst | 5 ++++-
Documentation/scheduler/sched-bwc.rst | 14 ++++++++------
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index aed195a71cbf..9f5e43d96476 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1200,7 +1200,10 @@ will be referred to. All time durations are in microseconds.
which indicates that the group may consume up to $MAX in each
$PERIOD duration. "max" for $MAX indicates no limit. If only
- one number is written, $MAX is updated.
+ one number is written, $MAX is updated. When a finite $MAX is
+ written, an existing cpu.max.burst value which is incompatible
+ with the new limit is reset to zero. Writing "max" leaves the
+ burst value unchanged.
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..79bd5f254e50 100644
--- a/Documentation/scheduler/sched-bwc.rst
+++ b/Documentation/scheduler/sched-bwc.rst
@@ -90,14 +90,16 @@ 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 positive value will enact the specified bandwidth limit. If
+the existing cpu.cfs_burst_us value is incompatible with the new quota, it is
+reset to zero. 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.
+and return the group to an unconstrained state once more. The existing
+cpu.cfs_burst_us value remains unchanged.
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
--
2.25.1
prev parent reply other threads:[~2026-08-20 3:33 UTC|newest]
Thread overview: 5+ 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-08-20 3:32 ` Zhe Liu [this message]
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=20260820033218.214259-3-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