Re: [PATCH] sched/fair: Skip NUMA balancing scan on memoryless nodes

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

Hello Phineas,

On 7/30/2026 11:21 PM, Phineas Su wrote:
> On systems with memoryless NUMA nodes (e.g. CPU-only nodes created via
> memory hiding, socket topologies with unpopulated memory, or CPU-only
> NUMA nodes), tasks running on these CPUs cause automatic NUMA balancing
> (kernel.numa_balancing=1) to repeatedly schedule task_numa_work() from
> task_tick_numa().
> 
> When task_numa_work() executes, it unmaps VMAs (PROT_NONE) to induce
> NUMA hinting faults (do_numa_page()). Fault handling then attempts page
> migration (migrate_misplaced_folio()) to the task's current CPU NUMA
> node. However, because the node has no managed memory (N_MEMORY is
> false), page allocations continuously fail (TNF_MIGRATE_FAIL), while
> task_tick_numa() repeatedly reschedules VMA scanning every scan period.

Isn't task_numa_work() also responsible for scanning? Inhibiting that
can be problematic - task can perhaps move to a node which has both CPUs
and memory and the hinting faults can help determine that.

I feel the page migration to !N_MEMORY node should be inhibited at
numa_migrate_check() on the mm side rather than skipping the
task_numa_work() entirely which can still be beneficial.

task_numa_fault() on the failure path there can instead move the task to
the node with CPU where the hot pages reside instead of trying to move
the pages to the node where task is running which, as it turns out, has
no memory to accept these pages.

Am I missing something?

> This results in heavy kernel system overhead (%sys CPU usage spiking up
> to ~78%) and continuous page fault storms without any possible NUMA
> placement benefit.

Now if you have a case where task is moveable only between a set of
nodes that don't have any memory and the hinting fault overhead keeps
adding up, that is a different problem.

> 
> Fix this by:
> 1. Checking node_state(task_node(curr), N_MEMORY) in task_tick_numa() so
>    tasks executing on CPUs of memoryless nodes do not schedule
>    numa_work callbacks via task_work_add().
> 2. Checking node_state(task_node(p), N_MEMORY) in task_numa_work() as a
>    safeguard to immediately abort VMA scanning if a task migrated to a
>    memoryless node while numa_work was already enqueued.
> 
> Signed-off-by: Phineas Su <pohaosu@google.com>
> ---
>  kernel/sched/fair.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index d78467ec6ee1..214cf0f2c692 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4101,6 +4101,9 @@ static void task_numa_work(struct callback_head *work)
>         if (p->flags & PF_EXITING)
>                 return;
> 
> +       if (!node_state(task_node(p), N_MEMORY))
> +               return;
> +
>         /*
>          * Memory is pinned to only one NUMA node via cpuset.mems, naturally
>          * no page can be migrated.
> @@ -4391,6 +4394,9 @@ static void task_tick_numa(struct rq *rq, struct task_struct *curr)
>         if (!curr->mm || (curr->flags & (PF_EXITING | PF_KTHREAD)) || work->next != work)
>                 return;
> 
> +       if (!node_state(task_node(curr), N_MEMORY))
> +               return;
> +
>         /*
>          * Using runtime rather than walltime has the dual advantage that
>          * we (mostly) drive the selection from busy threads and that the
> --
> 2.55.0.508.g3f0d502094-goog
> 

-- 
Thanks and Regards,
Prateek