Re: [PATCH] sched_ext: Print deprecation warnings only once

From: Breno Leitao

Date: Wed Jun 24 2026 - 04:26:37 EST


Hello Andrea,

On Tue, Jun 23, 2026 at 07:33:55PM +0200, Andrea Righi wrote:

> Hm... actually thinking more about it, the existing behavior seems fine already.

I have very few hosts in the Meta fleet that are unnecessarily spammy:

# dmesg | grep -c "ops->cpu_acquire/release() are deprecated, use sched_switch TP instead"
73
# dmesg | grep -c "sched_ext: Writing directly to p->scx.slice/dsq_vtime is deprecated, use scx_bpf_task_set_slice/dsq_vtime()"
855

And they are unnecessary, given they show up many times within the same
second, like, 42x times in last second:


# dmesg | grep "sched_ext: Writing directly to p->scx.slice/dsq_vtime is deprecated" | grep 806105 | wc -l
42
# dmesg | grep "sched_ext: Writing directly to p->scx.slice/dsq_vtime is deprecated" | grep 806105 | head
# [806105.018400] sched_ext: Writing directly to p->scx.slice/dsq_vtime is deprecated, use scx_bpf_task_set_slice/dsq_vtime()
# [806105.042160] sched_ext: Writing directly to p->scx.slice/dsq_vtime is deprecated, use scx_bpf_task_set_slice/dsq_vtime()
# [806105.065668] sched_ext: Writing directly to p->scx.slice/dsq_vtime is deprecated, use scx_bpf_task_set_slice/dsq_vtime()
...
>
> The ops->cpu_acquire/release() warning is only emitted from validate_ops(),
> which runs when the scheduler is registered. It's not in the runtime callback
> path, so we should already get one warning per scheduler registration. That
> means we don't need a warned_deprecated_cpu_rel flag.
>
> For slice/dsq_vtime, the warning is emitted when the verifier sees write
> accesses to those fields. It can fire multiple times while loading one sched_ext
> scheduler, depending on how many such accesses the verifier observes, but this
> also seems correct.
>
> If we want to prevent potential log spam maybe we can just change those
> pr_warn() to pr_warn_ratelimited()?

Ack, let me transform these pr_warn() in pr_warn_ratelimted() then.

THanks