Re: [PATCH 3/6] sched/numa: Notify the scheduling class of preferred node changes

[K Prateek Nayak]

Hello Andrea,

>> On 10/27/2026 9:43 AM, Andrea Righi wrote:
>>> --- a/kernel/sched/core.c
>>> +++ b/kernel/sched/core.c
>>> @@ -8331,8 +8331,13 @@ int migrate_task_to(struct task_struct *p, int target_cpu)
>>>  void sched_setnuma(struct task_struct *p, int nid)
>>>  {
>>>  	guard(task_rq_lock)(p);
>>> -	scoped_guard (sched_change, p, DEQUEUE_SAVE)
>>> +	scoped_guard (sched_change, p, DEQUEUE_SAVE) {
>>> +		bool changed = p->numa_preferred_nid != nid;
>>
>> Don't the callers of sched_setnuma() already check for this?
>>
>> Only one that doesn't is task_numa_migrate() but
>> numa_migrate_preferred() only calls it when
>> "task_node(p) == p->numa_preferred_nid" is false and "!sd "case resets
>> "p->numa_preferred_nid" to "task_node(p)" when the task cannot be
>> migrated.
>>
>> Afaict, "changed" is always true here. Is there a scenario that I might
>> be missing?
> 
> With the current callers it's always true for the tasks that can reach
> the callback.
> 
>  added the check just because ->numa_node_changed() is a generic
> sched_class callback and its contract is that it's invoked only when the
> preferred node actually changes. Checking it in sched_setnuma(), under
> the rq lock we're already holding, makes sure that the contract is
> honored independently of what the callers of sched_setnuma() are doing,
> now and in the future, instead of relying on each of them to check it.
> 
> That said, I don't have a strong opinion on that, if we prefer to keep
> sched_setnuma() minimal, I can drop the check and document that the
> callers must only invoke it on a change.

I too don't have a strong opinion but I'm all for smaller diffstat
whenever possible ;-)

Let us wait on Peter in case he would prefer to have the defensive
check. FWIW, I've been running a kernel with a:

  WARN_ON_ONCE(p->numa_preferred_nid == nid)

for a while and I haven't hit any warnings yet from sched_setnuma().

-- 
Thanks and Regards,
Prateek

"Program testing can be used to show the presence of bugs,
 but never to show their absence!" - Edsger W. Dijkstra