Re: [PATCH 11/13] sched_ext: Add scx_cpu0 example scheduler

[Tejun Heo <tj@kernel.org>]

On Mon, Nov 10, 2025 at 09:36:46AM +0100, Andrea Righi wrote:
> > +void BPF_STRUCT_OPS(cpu0_enqueue, struct task_struct *p, u64 enq_flags)
> > +{
> > +	if (p->nr_cpus_allowed < nr_cpus) {
> 
> We could be even more aggressive with DSQ_CPU0 and check
> bpf_cpumask_test_cpu(0, p->cpus_ptr), but this is fine as well.

I did the following instead:

  void BPF_STRUCT_OPS(cpu0_enqueue, struct task_struct *p, u64 enq_flags)
  {
          /*
           * select_cpu() always picks CPU0. If @p is not on CPU0, it can't run on
           * CPU 0. Queue on whichever CPU it's currently only.
           */
          if (scx_bpf_task_cpu(p) != 0) {
                  stat_inc(0);	/* count local queueing */
                  scx_bpf_dsq_insert(p, SCX_DSQ_LOCAL, SCX_SLICE_DFL, 0);
                  return;
          }

          stat_inc(1);	/* count cpu0 queueing */
          scx_bpf_dsq_insert(p, DSQ_CPU0, SCX_SLICE_DFL, enq_flags);
  }

This should be safe against migration disabled tasks and so on.

> > +		stat_inc(0);	/* count local queueing */
> > +		scx_bpf_dsq_insert(p, SCX_DSQ_LOCAL, SCX_SLICE_DFL, 0);
> 
> And this is why I was suggesting to automatically fallback to the new
> global default time slice internally. In this case do we want to preserve
> the old 20ms default or automatically switch to the new one?

Maybe SCX_SLICE_DFL can become runtime loaded const volatile but anyone
who's using it is just saying "I don't care". As long as it's not something
that breaks the system left and right, does it matter what exact value it
is?

Thanks.

-- 
tejun