Re: [PATCH 1/2] sched/fair: expose cpu.max.runtime to set bandwidth runtime directly

[Tejun Heo]

Hello,

On Thu, May 28, 2026 at 08:54:28AM +0200, Fernand Sieber wrote:
> 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.

Can you please go into more details, preferably a lot more? From cgroup POV,
there is a precedent for this sort of direct-ish low level control in
memory.reclaim; however, as things like this can create a lot of
implementation detail exposure, and I think the bar for use case
justification should be pretty high - the use cases should make general
sense and there are no other reasonable ways to achieve the same without
adding the proposed interface. I don't think the above description achieves
that.

Thanks.

-- 
tejun