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

[K Prateek Nayak <kprateek.nayak@amd.com>]

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?
> 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.

I think for fair, since there are no other fair tasks, it is indeed a
CPU without load - much like an idle CPU. NUMA balancing also looks
at load imbalance on the migrate swap path and it wouldn't have seen
the load back then either :-) 
> 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?

Ack! I think you can keep that check. Let us not disturb a CPU just
because it is preemptible if there is a better option / idle CPUs
around.

-- 
Thanks and Regards,
Prateek