Re: [PATCH 6/6] sched/numa: ignore preferred nodes without normal balancing

From: Li Zhe

Date: Thu Oct 15 2026 - 07:45:22 EST


On 10/14/26 9:30 PM, Gregory Price wrote:
> On Wed, Oct 14, 2026 at 05:43:47PM +0800, Li Zhe wrote:
>> numa_preferred_nid is normal AutoNUMA task-placement state.
>> Memory-tiering-only mode uses NUMA hint faults to drive page promotion,
>> not CPU placement.
>>
>> Even after tiering-only faults stop updating normal placement statistics,
>> a task can still have a preferred NUMA node from earlier normal balancing
>> or from previously polluted state. Several scheduler paths consume that
>> stale state when the NUMA balancing static key is enabled, including
>> explicit NUMA task migration, sched-cache preferred LLC and scan CPU mask
>> selection, load-balance locality checks, fbq classification, and wakeup
>> group selection.
>>
>> Add a small helper for normal NUMA placement being enabled and use it to
>> ignore numa_preferred_nid when NUMA_BALANCING_NORMAL is disabled. Keep
>> the preferred-node migration retry timestamp update before the normal-mode
>> check so accepted non-normal sysctl states do not leave stale retry state
>> behind.
>>
>> Keep the rq nr_numa_running and nr_preferred_running accounting unchanged
>> so runtime mode changes do not make enqueue/dequeue accounting asymmetric;
>> the load balancer simply stops consuming those counters while normal
>> balancing is off.
>>
>> This does not clear numa_preferred_nid and does not change memory-tiering
>> promotion decisions.
>>
> Same feedback - need to present user-facing performance changes to show
> the impact of this change.
>
> Sashiko also has some correctness feedback.
Thanks for the review.

For the performance side, I do not have convincing user-facing
performance numbers for this patch. Similar to patches 3 and 5, this was
written from the code/semantic correctness side for memory-tiering-only
mode, rather than as a general improvement for normal NUMA balancing
workloads.

I did not see Sashiko's correctness feedback on the public thread. Could
you share it here, or ask Sashiko to reply on-list? That would help me
understand the exact issue and make sure the next version addresses it.

Thanks,
Zhe

>
> ~Gregory