Linux Documentation
 help / color / mirror / Atom feed
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


      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