Re: [PATCH 2/6] sched/numa: Leave the placement of a BPF-scheduled task to its scheduler

[Andrea Righi]

Hi Prateek,

On Tue, Oct 27, 2026 at 11:15:58AM +0530, K Prateek Nayak wrote:
> Hello Andrea,
> 
> On 10/27/2026 9:43 AM, Andrea Righi wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 36df9a4dde534..5064c7b707f4d 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -3267,8 +3267,13 @@ static bool task_numa_compare(struct task_numa_env *env,
> >  
> >  	rcu_read_lock();
> >  	cur = rcu_dereference_all(dst_rq->curr);
> > +	/*
> > +	 * Never pick a task under a BPF scheduler as the swap partner: its
> > +	 * placement is left to that scheduler, see numa_migrate_preferred().
> > +	 * Moving the faulting task alone to the destination is still allowed.
> > +	 */
> >  	if (cur && ((cur->flags & (PF_EXITING | PF_KTHREAD)) ||
> > -		    !cur->mm))
> > +		    !cur->mm || task_on_scx(cur)))
> 
> So if you are here, it must be from:
> 
>   task_numa_migrate()
>     task_numa_find_cpu()
>       task_numa_compare()
> 
> but task_on_scx(p) would skip this and it means a fair task is looking
> for a swap candidate when scx running in partial mode right?

Correct.

> 
> At that point, it feels fair class should be well within its rights to
> call shots on the swap candidate even if it is an scx task.
> 
> If scx has a ops.set_numa() defined, it would have accumulated hinting
> faults and the CPU it is running on is a wrong node anyways so the
> migration shouldn't be bad in grand scheme of things. If ops.set_numa()
> is not defined, then the scheduler doesn't care about NUMA placement
> and it should be okay for a fair task to acquire that CPU.

The fair task can still acquire that CPU: with cur = NULL,
task_numa_compare() can still pick the destination CPU for the fair task
alone, and once it's there it'll preempt the sched_ext task, since fair
wins over scx. What the check prevents is only the other half of the
swap, which is fair moving the scx task to the source CPU, overriding
the placement decided by the BPF scheduler (the idea is that fair should
be able to preempt scx, but not override scx's task placement).

And the fact that the scx task is not on its preferred node doesn't
necessarily mean that it's on the wrong node: the preferred node only
tracks memory locality, but the BPF scheduler may have placed the task
there on purpose for other reasons (e.g., close to a device, which is
one of the use cases that motivated this work), using the preferred node
only as a hint.

There's also a more practical problem: the swap decision is based on
data that isn't maintained for sched_ext tasks. task_numa_compare()
does:

	load = task_h_load(env->p) - task_h_load(cur);

and for an scx task se.avg is not updated, so task_h_load(cur) reflects
whatever load the task had when it left fair. Similarly, if the BPF
scheduler doesn't implement ops.set_numa_node(), the task isn't scanned,
so its NUMA fault statistics are stale as well. So fair would be
deciding the swap based on frozen values.

So I think it makes sense to apply the same principle as in
numa_migrate_preferred() also to the other task involved in the swap.

What do you think?

Thanks,
-Andrea

> 
> >  		cur = NULL;
> >  
> >  	/*
> > @@ -3645,6 +3650,14 @@ static void numa_migrate_preferred(struct task_struct *p)
> >  	if (task_node(p) == p->numa_preferred_nid)
> >  		return;
> >  
> > +	/*
> > +	 * A task under a BPF scheduler is placed by that scheduler. Keep the
> > +	 * statistics coming, which is what makes p->numa_preferred_nid worth
> > +	 * reading, but leave the placement alone.
> > +	 */
> > +	if (task_on_scx(p))
> > +		return;
> > +
> 
> Restricting ext on this path seems fine.
> 
> >  	/* Otherwise, try migrate to a CPU on the preferred node */
> >  	task_numa_migrate(p);
> >  }
> 
> -- 
> Thanks and Regards,
> Prateek
>