Re: [PATCH 3/6] sched/numa: fix scan-period adjustment for shared faults

["Li Zhe" <lizhe.67@bytedance.com>]

On 10/14/26 9:12 PM, Gregory Price wrote:
> On Wed, Oct 14, 2026 at 05:43:44PM +0800, Li Zhe wrote:
>> Commit 37ec97deb3a8 ("sched/numa: Slow down scan rate if shared faults
>> dominate") intended to slow scanning when either shared or local faults
>> dominate, and to speed scanning up only when many private faults are on
>> remote memory pages.
>>
>> The implementation uses the private-fault ratio as the slow-scan signal.
>> That makes private-dominated samples slow scanning, while
>> shared-dominated samples can still fall through to the speed-up path.
>> That does not match the stated intent.
>>
>> Replacing the private ratio with a shared ratio fixes the
>> shared-dominated case, but the scan-period code still only has separate
>> locality and sharing ratios. Those ratios cannot distinguish a window
>> with many remote shared faults and only a few remote private faults from
>> one with substantial remote private faults.
>>
>> Track faults that are both remote and private, and only speed up scanning
>> when that signal is large enough. This keeps local or shared samples
>> slowing scanning and avoids extra hinting overhead when the remote
>> activity is mostly shared.
>>
> This changes NUMA balancing behavior that's been around since 2017.
>
> While it's not the stated intent, it's been consistent since then,
> and i'm concerned that this could cause unexpected regressions.
>
> Do you have performance numbers on this change to show it's actually
> beneficial compared to the existing behavior?


Thanks for the review.

I do not have convincing performance numbers to show that this is broadly
beneficial across workloads. NUMA balancing heuristics are
workload-dependent, and my motivation here was mainly the consistency of
the scan-period decision logic rather than a broad performance claim.

The same concern also applies to patches 5 and 6. They were written from
the code/semantic correctness side, but I do not have convincing workload
numbers to show that they are broadly beneficial.

For `update_task_scan_period()`, there is a more concrete issue in the
memory-tiering-only case. The function currently depends on normal NUMA
placement fault statistics. In memory-tiering-only mode, when there is no
useful normal-placement feedback, it can keep taking the slow-down path
and grow the scan period towards the maximum. I am testing a separate
patch locally to handle the memory-tiering-only scan feedback explicitly.

So I think I should separate the severe fixes from the heuristic changes.
For the latter, I will narrow the next version to NUMA balancing behavior
that is specific to memory tiering, instead of trying to justify the
changes as general improvements for normal NUMA balancing workloads.

Thanks,
Zhe

>
> ~Gregory