Re: [PATCH] mm/numa_balancing: allow migrate on protnone reference with MPOL_WEIGHTED_INTERLEAVE policy

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

On 9/30/26 5:11 PM, Gregory Price wrote:
> On Wed, Sep 30, 2026 at 04:59:50PM +0800, Li Zhe wrote:
>> On 9/30/26 4:43 PM, Gregory Price wrote:
>>> On Wed, Sep 30, 2026 at 03:26:17PM +0800, Li Zhe wrote:
>>>> Allow MPOL_F_NUMA_BALANCING for MPOL_WEIGHTED_INTERLEAVE.  As with
>>>> MPOL_BIND and MPOL_PREFERRED_MANY, keep migration constrained by the
>>>> policy nodemask: if the CPU's node is outside the nodemask, do not
>>>> migrate the folio there.
>>>>
>>> Why for WEIGHTED_INTERLEAVE and not INTERLEAVE as well?
>>
>> Thanks for pointing this out.
>>
>> I focused on MPOL_WEIGHTED_INTERLEAVE in v1 because the motivating use
>> case is to seed memory across tiers with a configurable ratio at
>> allocation time, and then let NUMA balancing/memory tiering adjust the
>> placement based on access patterns. With equal weights,
>> MPOL_WEIGHTED_INTERLEAVE can also cover the regular interleave
>> allocation pattern.
>>
>> That said, I agree that MPOL_INTERLEAVE can be handled consistently as
>> well. Since this is still an explicit opt-in via MPOL_F_NUMA_BALANCING,
>> unless others see a reason to keep MPOL_INTERLEAVE out, I will extend
>> this in v2 to cover both MPOL_INTERLEAVE and MPOL_WEIGHTED_INTERLEAVE
>> with the same nodemask constraint.
>>
> Looking at it, is there an actual reason to limit F_MORON at all? Or
> should we just lift
>
>                  if (pol->flags & MPOL_F_MORON) {
>                          /*
>                           * Optimize placement among multiple nodes
>                           * via NUMA balancing
>                           */
>                          if (node_isset(thisnid, pol->nodes))
>                                  break;
>                          goto out;
>                  }
>
> Out ahead of everything?
Yes, that makes sense to me.

I do not see a reason to keep the MPOL_F_MORON handling limited to
specific policy cases. The flag already means that migrate-on-fault
placement should target the accessing CPU's node, and the nodemask check
is the common constraint we want for all policies that opt in to this
behavior.

I will rework v2 to handle MPOL_F_MORON before the policy-specific
switch. Then the switch can remain responsible for the non-MPOL_F_MORON
misplaced logic, while MPOL_BIND, MPOL_PREFERRED_MANY, MPOL_INTERLEAVE
and MPOL_WEIGHTED_INTERLEAVE can share the same migrate-on-fault path.

Thanks,
Zhe

>
> ~Gregory