mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Michal Koutný" <mkoutny@suse.com>
To: Zhe Liu <liuzhe1@kylinos.cn>
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, 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,
	stable@vger.kernel.org
Subject: Re: [PATCH v2 1/3] sched/fair: Remove the write-order dependency between cpu.max and cpu.max.burst
Date: Mon, 7 Sep 2026 16:06:31 +0200	[thread overview]
Message-ID: <ap69-MoOmAJifgjG@localhost.localdomain> (raw)
In-Reply-To: <20260904062013.504236-2-liuzhe1@kylinos.cn>

[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

On Fri, Sep 04, 2026 at 02:20:11PM +0800, Zhe Liu <liuzhe1@kylinos.cn> wrote:
> Keep the configured burst independent of the current quota and cap it
> when CFS refills runtime. This allows quota and burst updates in either
> order.
> 
> Fixes: f4183717b370 ("sched/fair: Introduce the burstable CFS controller")
> 
> Cc: stable@vger.kernel.org

The change makes sense to me and it should've been like that from the
beginning. OTOH, it may break someone's setup, so I'd take it but revert
it should regressions be reported. Hence, I wouldn't mark it for stable. 


> Signed-off-by: Zhe Liu <liuzhe1@kylinos.cn>
> ---
>  kernel/sched/core.c | 3 +--
>  kernel/sched/fair.c | 3 ++-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index f78275192036..5269b8cfcf7f 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -10159,8 +10159,7 @@ static int tg_set_bandwidth(struct task_group *tg,
>  	if (quota_us != RUNTIME_INF && quota_us > max_bw_runtime_us)
>  		return -EINVAL;
>  
> -	if (quota_us != RUNTIME_INF && (burst_us > quota_us ||
> -					burst_us + quota_us > max_bw_runtime_us))
> +	if (burst_us > max_bw_runtime_us)
>  		return -EINVAL;

I notice this'd be relaxed rather like:

	if (burst_us > max_bw_runtime_us / 2)
		return -EINVAL;

I don't see in the current code that these BW_SHIFT'd calculations were
relevant for burst.
(Sashiko mentions overflows of the addition but I think it's confused
MAX_BW and UULONG_MAX or more precisely (UULONG_MAX / NSEC_PER_USEC),)
so even your version should still be safe.

(Without that stable annotation above.)

Reviewed-by: Michal Koutný <mkoutny@suse.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

  parent reply	other threads:[~2026-09-07 14:06 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ý [this message]
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       ` [PATCH v2 3/3] Documentation: describe CPU quota and burst ordering Zhe Liu
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=ap69-MoOmAJifgjG@localhost.localdomain \
    --to=mkoutny@suse.com \
    --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=liuzhe1@kylinos.cn \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=skhan@linuxfoundation.org \
    --cc=stable@vger.kernel.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®