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

[Andrea Righi <arighi@nvidia.com>]

Hi Breno,

On Tue, Jun 23, 2026 at 09:45:06AM -0700, Breno Leitao wrote:
> On Tue, Jun 23, 2026 at 05:53:33PM +0200, Andrea Righi wrote:
> > Hi Breno and Christian,
> > 
> > On Tue, Jun 23, 2026 at 04:45:55PM +0100, Christian Loehle wrote:
> > > On 6/23/26 15:38, Breno Leitao wrote:
> > > > The deprecation notices for direct p->scx.slice/dsq_vtime writes and for
> > > > ops->cpu_acquire/release() use plain pr_warn(), so they repeat on every
> > > > scheduler (re)load and flood the kernel log.
> > > > > The slice/dsq_vtime notice is emitted from the BPF verifier's
> > > > btf_struct_access callback, which runs once per write access and is
> > > > re-evaluated as the verifier explores paths, so loading a single
> > > > scheduler can print it several times. The cpu_acquire/release notice is
> > > > printed on every scheduler enable.
> > > > 
> > > > Switch both to pr_warn_once() so each deprecation is reported a single
> > > > time, and add the missing newline to the slice/dsq_vtime message.
> > > 
> > > I guess this should be warned for once per BPF scheduler like
> > > sch->warned_deprecated_rq
> > 
> > Yeah, I agree. The thing is that we can load multiple different BPF schedulers,
> > and we'd want to get these messages for each of them. So ideally we need
> > something like sch->warned_deprecated_rq.
> 
> Agreed, pr_warn_once() is too coarse - it mutes the notice for every
> scheduler loaded after the first one since boot.
> 
> For ops->cpu_acquire/release() this is easy: the notice comes from
> validate_ops(), which has the scx_sched, so I'll gate it on a
> per-scheduler warned_deprecated_cpu_rel flag, just like
> warned_deprecated_rq.
> 
> The slice/dsq_vtime notice is the one I wanted to ask about. It's
> emitted from bpf_scx_btf_struct_access(), the .btf_struct_access
> verifier callback.
> 
> That runs at program load/verification time, before the struct_ops is
> registered and the scx_sched is allocated (that only happens later in
> scx_enable()). Any idea on what to do in this case?

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

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()?

Thanks,
-Andrea