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

[Andrea Righi <arighi@nvidia.com>]

On Tue, Oct 27, 2026 at 02:30:31PM +0530, K Prateek Nayak wrote:
> Hello Andrea,
> 
> On 10/27/2026 12:13 PM, Andrea Righi wrote:
> >> 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).
> 
> I guess that is fair - if there is a better target, it should be
> preferred. 
> > 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.
> 
> But is anyone running ext in partial mode expecting good performance
> without having moved a ton of tasks to ext beforehand?

Yeah, partial mode has always been a bit controversial, users of this
mode are mostly those that rely on fair-specific features (e.g., EAS)
but still want to experiment with sched_ext. And to make it work
effectively, the best approach is to statically partition the system, to
avoid mixing fair and ext tasks on the same CPUs.

In that scenario I think it's even more important to not let fair move
scx tasks around. Hopefully, once the ext class is able to provides all
the features that fair provides, we can stop supporting partial mode.

Thanks,
-Andrea