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

Tao Cui <[email protected]>
Newsgroups dev.linux.lists.sched-ext,org.kernel.vger.bpf,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
From: Tao Cui <[email protected]>

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.

Signed-off-by: Tao Cui <[email protected]>
---
 kernel/sched/ext/ext.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
index 10af28a9f2c0..de786d0b928a 100644
--- a/kernel/sched/ext/ext.c
+++ b/kernel/sched/ext/ext.c
@@ -4953,6 +4953,12 @@ void scx_group_set_bandwidth(struct task_group *tg,
 	     tg->scx.bw_burst_us != burst_us))
 		SCX_CALL_OP(sch, cgroup_set_bandwidth, NULL,
 			    tg_cgrp(tg), period_us, quota_us, burst_us);
+	else if (scx_cgroup_enabled && sch &&
+		 !SCX_HAS_OP(sch, cgroup_set_bandwidth) &&
+		 quota_us != RUNTIME_INF)
+		pr_warn_once("sched_ext: BPF scheduler \"%s\" does not implement "
+			     "ops.cgroup_set_bandwidth(); cpu.max will not be enforced\n",
+			     sch->ops.name);
 
 	tg->scx.bw_period_us = period_us;
 	tg->scx.bw_quota_us = quota_us;
-- 
2.43.0
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.