From: bot+bpf-ci@kernel.org
To: sieberf@amazon.com,mingo@redhat.com,peterz@infradead.org,juri.lelli@redhat.com,vincent.guittot@linaro.org,tj@kernel.org
Cc: bsegall@google.com,dietmar.eggemann@arm.com,rostedt@goodmis.org,mgorman@suse.de,vschneid@redhat.com,kprateek.nayak@amd.com,hannes@cmpxchg.org,mkoutny@suse.com,void@manifault.com,arighi@nvidia.com,changwoo@igalia.com,skhan@linuxfoundation.org,corbet@lwn.net,rdunlap@infradead.org,cgroups@vger.kernel.org,sched-ext@lists.linux.dev,linux-doc@vger.kernel.org,linux-kselftest@vger.kernel.org,bpf@vger.kernel.org,linux-kernel@vger.kernel.org,nh-open-source@amazon.com,hborghor@amazon.de,fmubeen@amazon.de,dwmw@amazon.co.uk,karataev@amazon.com,sieberf@amazon.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev
Subject: Re: [PATCH v2 1/4] sched/fair: expose cpu.max.runtime to set bandwidth runtime directly
Date: Wed, 11 Nov 2026 08:28:16 +0000 (UTC) [thread overview]
Message-ID: <6829aa96d3cda5fdc47f3040dfed6fd7c9c9e92d2dbd7a3ec5f138508db987f8@mail.kernel.org> (raw)
In-Reply-To: <9741224b8d2b19760f85c1f854d61f30fa7d9710.1794303670.git.sieberf@amazon.com>
[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]
> sched/fair: expose cpu.max.runtime to set bandwidth runtime directly
TL;DR: In fair.c, cpu.max.runtime may return stale leftover runtime (e.g.
50000) after a group is switched to "max" quota, while writes fail; a
behaviour question about returning 0 or failing the read.
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
[ ... ]
> +u64 cfs_bandwidth_get_runtime(struct cfs_bandwidth *cfs_b)
> +{
> + u64 runtime;
> +
> + guard(raw_spinlock_irq)(&cfs_b->lock);
> +
> + runtime = cfs_b->runtime;
> + if (cfs_b->quota != RUNTIME_INF)
> + runtime = min(runtime, cfs_b->quota + cfs_b->burst);
> +
> + return runtime;
> +}
When the group is switched to "max", does cpu.max.runtime return a stale
value?
tg_set_cfs_bandwidth() calls __refill_cfs_bandwidth_runtime(), which
returns early when quota is RUNTIME_INF:
if (unlikely(cfs_b->quota == RUNTIME_INF))
return;
After that nothing updates cfs_b->runtime, so the value left over from
the last finite quota is returned uncapped here.
For example, write "50000 100000" to cpu.max, leave the group idle, then
write "max 100000". cpu.max.runtime keeps reading 50000 for as long as
the group is unlimited, while a group that never had a quota reads 0.
Writes fail with EINVAL in that state, but the read reports runtime the
group does not have and that is not being tracked.
Should this return a defined value (for example 0) when quota is
RUNTIME_INF, or fail the read the way the write fails?
This is documented as "The runtime the cgroup has accumulated and not
used yet", which has no meaning for an unconstrained group.
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/42982707042
next prev parent reply other threads:[~2026-11-11 8:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 11:08 [PATCH v2 0/4] sched/fair: cpu.max.runtime and idle refill for CPU credits Fernand Sieber
2026-11-10 11:08 ` [PATCH v2 1/4] sched/fair: expose cpu.max.runtime to set bandwidth runtime directly Fernand Sieber
2026-11-11 8:28 ` bot+bpf-ci [this message]
2026-11-10 11:08 ` [PATCH v2 2/4] sched/fair: refill bandwidth for the periods the timer slept through Fernand Sieber
2026-11-10 11:08 ` [PATCH v2 3/4] sched_ext: add cgroup_set_runtime ops callback Fernand Sieber
2026-11-11 8:08 ` bot+bpf-ci
2026-11-10 11:08 ` [PATCH v2 4/4] sched_ext: charge BPF scheduler tasks to cpu.max bandwidth Fernand Sieber
2026-11-11 8:28 ` bot+bpf-ci
2026-11-10 20:10 ` [PATCH v2 0/4] sched/fair: cpu.max.runtime and idle refill for CPU credits Tejun Heo
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=6829aa96d3cda5fdc47f3040dfed6fd7c9c9e92d2dbd7a3ec5f138508db987f8@mail.kernel.org \
--to=bot+bpf-ci@kernel.org \
--cc=andrii@kernel.org \
--cc=arighi@nvidia.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=bsegall@google.com \
--cc=cgroups@vger.kernel.org \
--cc=changwoo@igalia.com \
--cc=corbet@lwn.net \
--cc=daniel@iogearbox.net \
--cc=dietmar.eggemann@arm.com \
--cc=dwmw@amazon.co.uk \
--cc=eddyz87@gmail.com \
--cc=fmubeen@amazon.de \
--cc=hannes@cmpxchg.org \
--cc=hborghor@amazon.de \
--cc=ihor.solodrai@linux.dev \
--cc=juri.lelli@redhat.com \
--cc=karataev@amazon.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=martin.lau@kernel.org \
--cc=mason@kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=mkoutny@suse.com \
--cc=nh-open-source@amazon.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sched-ext@lists.linux.dev \
--cc=sieberf@amazon.com \
--cc=skhan@linuxfoundation.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=void@manifault.com \
--cc=vschneid@redhat.com \
--cc=yonghong.song@linux.dev \
/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®