From: Fernand Sieber <sieberf@amazon.com>
To: <tj@kernel.org>
Cc: <arighi@nvidia.com>, <bsegall@google.com>, <changwoo@igalia.com>,
<dietmar.eggemann@arm.com>, <dwmw@amazon.co.uk>,
<fmubeen@amazon.de>, <hborghor@amazon.de>,
<juri.lelli@redhat.com>, <linux-kernel@vger.kernel.org>,
<mgorman@suse.de>, <mingo@redhat.com>,
<nh-open-source@amazon.com>, <peterz@infradead.org>,
<sieberf@amazon.com>, <vincent.guittot@linaro.org>,
<void@manifault.com>
Subject: Re: [PATCH 1/2] sched/fair: expose cpu.max.runtime to set bandwidth runtime directly
Date: Thu, 28 May 2026 08:54:28 +0200 [thread overview]
Message-ID: <20260528065428.69225-1-sieberf@amazon.com> (raw)
In-Reply-To: <ahdARaXc-glZcTW4@slm.duckdns.org>
Hi Tejun,
On Wed, May 27, 2026 at 09:04:37AM -1000, Tejun Heo wrote:
> On Mon, May 25, 2026 at 09:36:21PM +0200, Fernand Sieber wrote:
> > Add a cpu.max.runtime cgroup v2 interface that allows userspace to
> > set the CFS bandwidth controller's runtime directly. This enables
> > CPU credit injection: an orchestrator writes a runtime budget which
> > the cgroup consumes naturally through the existing bandwidth
> > enforcement mechanism.
>
> Can you detail the use case? What problem is it solving how?
Our use case is managing CPU credits for VMs.
Product spec defines credits accumulation rate (quota), credits
limit (burst), and initial level of credits at launch (runtime).
Controlling runtime is also necessary for preserving credits across
live update (kexec) and live migration.
It is possible to approximate this behavior with existing kernel
primitives. However this requires setting up awkward parallel
accounting/control logic from userspace which must be periodically
synced up with the kernel. Instead, we propose minimal changes to
the cpu bw primitives to facilitate this use case.
Thanks.
Fernand
Amazon Development Centre (South Africa) (Proprietary) Limited
29 Gogosoa Street, Observatory, Cape Town, Western Cape, 7925, South Africa
Registration Number: 2004 / 034463 / 07
next prev parent reply other threads:[~2026-05-28 6:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-25 19:36 [PATCH 0/2] sched/fair: expose cpu.max.runtime for credit injection Fernand Sieber
2026-05-25 19:36 ` [PATCH 1/2] sched/fair: expose cpu.max.runtime to set bandwidth runtime directly Fernand Sieber
2026-05-26 20:52 ` Benjamin Segall
2026-05-28 7:25 ` Fernand Sieber
2026-05-27 19:04 ` Tejun Heo
2026-05-28 6:54 ` Fernand Sieber [this message]
2026-05-28 14:37 ` Tejun Heo
2026-05-25 19:36 ` [PATCH 2/2] sched/ext: add cgroup_set_runtime ops callback Fernand Sieber
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=20260528065428.69225-1-sieberf@amazon.com \
--to=sieberf@amazon.com \
--cc=arighi@nvidia.com \
--cc=bsegall@google.com \
--cc=changwoo@igalia.com \
--cc=dietmar.eggemann@arm.com \
--cc=dwmw@amazon.co.uk \
--cc=fmubeen@amazon.de \
--cc=hborghor@amazon.de \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=nh-open-source@amazon.com \
--cc=peterz@infradead.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=void@manifault.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.