Re: [PATCH RFC] sched_ext: warn when cpu.max is set but the BPF scheduler doesn't implement bandwidth control

[Tao Cui]

Hello,
在 2026/8/18 23:34, Tejun Heo 写道:
> Hello,
> 
> On Tue, Aug 18, 2026 at 09:53:28PM +0800, Tao Cui wrote:
>> From: Tao Cui <cuitao@xxxxxxxxxx>
>>
>> The kernel stores cpu.max bandwidth parameters in the task_group and
>> passes them to the BPF scheduler via ops.cgroup_set_bandwidth() and
>> scx_cgroup_init_args, but does not enforce the quota itself. If the
>> loaded BPF scheduler doesn't implement the callback, cpu.max is
>> silently ignored -- the cgroup gets unlimited CPU regardless of the
>> configured quota.
>>
>> Of the example schedulers, only scx_qmap implements the callback --
>> and only to bpf_printk() the parameters, so no in-tree scheduler
>> actually enforces the quota. Measured with scx_simple: a
>> cgroup with cpu.max = "50000 100000" (50% of one CPU) and one
>> busy task used 9946ms of CPU in 10 seconds with nr_throttled
>> remaining 0.
>>
>> Print a one-time warning when a finite quota is configured on a
>> cgroup while the active scheduler lacks the callback, so users and
>> container orchestrators know the quota is not enforced.
> 
> We had something similar with cpu.weight and it created more annoaynces than
> helping anything. cgroup bw control isn't the only thing the BPF scheduler
> may skip to implement. It can also choose to ignore e.g. nice levels
> completely too and there's no way to detect things like that. Documentation
> is probably the right way to handle this.
> 

Understood, the cpu.weight precedent makes sense: the scheduler may
ignore a whole set of knobs, and warning on just one of them would be
arbitrary.

I'll follow up with a patch to sched-ext.rst instead: a note that
cgroup CPU knobs like cpu.max only take effect if the loaded scheduler
implements the corresponding callbacks, and that schedulers may also
ignore things like nice levels.

Thanks,
Tao

> Thanks.
>