Re: [PATCH v2 2/3] sched/numa: do not feed tiering promotions into task placement stats

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

On 10/28/26 11:03 PM, Joshua Hahn wrote:
> On Wed, Oct 28, 2026 at 12:14 AM Li Zhe <lizhe.67@bytedance.com> wrote:
>> NUMA balancing has separate mode bits for normal task placement and
>> memory tiering. In memory-tiering-only mode, NUMA hinting faults on
>> slow-tier pages are used to detect hot pages and promote them to a top
>> tier. They are not normal task-placement faults.
>>
>> For slow-tier folios, memory tiering reuses the folio last-cpupid field
>> to store access-time metadata. numa_migrate_check() therefore cannot
>> return a real cpupid for those faults. Before this change, it returned the
>> same all-ones last_cpupid value that normal AutoNUMA uses for a first or
>> unknown access.
>>
>> That can make a memory-tiering-only promotion look like an ordinary first
>> private AutoNUMA fault. After a successful promotion, do_numa_page()
>> reports the target top-tier node to task_numa_fault(), so the existing
>> slow-node skip no longer applies. task_numa_fault() then accounts the
>> fault in p->numa_faults and p->numa_faults_locality, and
>> task_numa_placement() can consume that sample to update normal task
>> placement state even though normal NUMA balancing is disabled. In other
>> words, hot-page promotion feedback can leak into the CPU placement
>> heuristic.
> Hi Zhe,
>
> Thanks for the revision. To me, this looks more like a fix than an
> optimization, since there really is incorrect NUMA balancing behavior
> happening that could be visible in userspace (unintended
> task-placement and related accounting). On the other hand patch 3/3
> doesn't seem like a fix to me despite the name, since this one would
> mitigate the incorrect behavior.
>
> How about we pull this one out of the series and submit it
> independently with an appropriate Fixes: tag and cc:stable, and
> discuss 1 and 3 later on? Unfortunately this is also not a great time
> to submit new features or behaviors as we are in the middle of a large
> merge window, and there are a bunch of fixes that maintainers might be
> busy looking into : -(
>
> Regardless, thank you for the fix, Zhe! I don't have a strong
> preference on the ordering of this against pghot, but if other folks
> are concerned that this could create more churn, I think it would be
> reasonable to wait for patches 1 and 3 after we discuss with Bharata.
Thanks for the review.

Agreed, patch 2 is better framed as a fix.  I will check the exact
commit that introduced this path and can resend it separately with a
proper Fixes tag and Cc stable after rc1 is released.

For patches 1 and 3, I agree they are more about the tiering heuristic
and policy behavior.  I will keep them separate from the fix discussion
and continue that part together with the pghot-related discussion.

Thanks,
Zhe
>
> I hope you have a great day : -)
> Joshua