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

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Jul 30, 2026 at 05:51:51PM +0000, 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.
> 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.
> 
> 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.

Rather than fully disabling, I would argue the right thing is to ensure
the pages are nearest the node the task runs on.

That is, rather than force migrate to *this* node, ensure they are on a
node such that the distance to *this* node is minimal.

After all, the tasks still run here. Not migrating the memory just
because this node doesn't have memory might mean the memory stays
maximally far away, which is suboptimal.