Re: [PATCH v2 0/4] sched/fair: cpu.max.runtime and idle refill for CPU credits

[Tejun Heo]

Hello, Fernand.

On Tue, Nov 10, 2026 at 01:08:47PM +0200, Fernand Sieber wrote:
> This series adds cpu.max.runtime, a cgroup v2 file to read and set the
> runtime the CFS bandwidth controller has for a cgroup, lets
> cpu.max.burst exceed the quota, and makes an idle group keep earning
> quota up to quota + burst. Patch 3 passes the writes on to BPF
> schedulers, and patch 4 lets them charge their tasks to the same
> runtime.

I think this patchset is too maximalist. As described, the use case is
specific to selling burstable CPU budget. Nobody else has asked for
this. There may be other use cases which haven't been stated yet but the
description doesn't surface any, so as it stands this is pretty niche.

On top of that, the series integrates into both fair and sched_ext and
then makes the two work together so that the handoff is seamless. That's
too much for something which doesn't have a strong use case or an
established generic need. As with scx_bpf_cgroup_report_throttled(),
patch 4 modifies fair's internal state from sched_ext, which I don't
think is a good idea as the cgroup piping is split at the interface
level:

  https://lore.kernel.org/all/ahdFAZVnb3DTv8Jo@xxxxxxxxxxxxxxx/

Seamlessly switching tasks between the classes in partial mode has a lot
of other integration problems beyond this one and at least I'm not
aiming to achieve it. It'd cost a lot more than it'd be useful.

The sched_ext part can just be a feature of your own BPF scheduler,
which you seem to be using already. There, the credit level is just
state in your BPF maps which your userspace can read and set, so the
maximalist version can wait until the need is proven. If you want a
handover between your scheduler and fair, that can be done from
userspace.

If a burstable budget is something useful to add to fair, can you do
that first and separately? It should be able to stand on its own.

Thanks.

--
tejun