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

[Gregory Price]

On Fri, Oct 02, 2026 at 04:15:45PM +0800, Li Zhe wrote:
> On 10/2/26 3:56 PM, David Hildenbrand (Arm) wrote:
> > I can understand the "random initial placement will help if you cross your
> > fingers" argument from Zi.
> >
> > But then the question really is whether the app should then change the policy
> > after the initial placement was done and the weighted stuff no longer makes a
> > lot of sense.
> Yes, that model makes sense if the application or runtime can
> cooperate with the policy switch.
> 
> One limitation is that this is not fully transparent for existing
> workloads. set_mempolicy() updates the calling task's policy, and
> mbind() updates VMAs in the calling mm. move_pages() and
> migrate_pages() can move pages of another process, but they do not
> change that process's future allocation policy.
> 
> So I agree this staged approach is worth considering, but it also has
> some deployment cost for workloads that cannot participate in the
> policy switch.
>

if the use-case is vma (mbind), such a switch can make sense.

if the use-case is task policy (set_mempolicy), such a switch is
not a realistic solution.

In userspace we tend to use task policy by way of numactl:

  numactl --interleave=all ./my_program

This calls set_mempolicy for the numactl task and then exec's into
my_program with the inherited mempolicy.  That mempolicy is dup'd on
fork / clone.

Changing the mempolicy from that point requires every task in the
workload to call set_mempolicy() again.

There is no way to externally change another task's mempolicy.

I attempted this during the initial weighted-interleave exploration:

https://lore.kernel.org/all/20231122211200.31620-1-gregory.price@xxxxxxxxxxxx/

but we did not see the need for it once we landed on sysfs controls for
weights.  In addition - there are MANY `current` assumptions hard coded
into the mempolicy and cgroup stack - getting such things dug out would
be (will be?) very painful.

~Gregory