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

[David Hildenbrand (Arm)]

On 10/1/26 15:26, Gregory Price wrote:
> On Thu, Oct 01, 2026 at 12:54:22PM +0200, David Hildenbrand (Arm) wrote:
>>> If this is a initial-fill problem, can userspace set weighted interleave
>>> initially? The program or harness can observe memory usage of the program
>>> or related NUMA nodes and switch the policy to numa balancing via
>>> set_mempolicy() or mbind() without MPOL_MF_MOVE after certain threshold
>>> is met?
>>
>> You mean: use the weighted policy initially and then switch to a NUMA-balancing
>> one which doesn't involve the weights anymore?
>>
>> That makes more sense to me. Although I struggle to see why an effectively
>> "let's put random memory on slow and others at hot" is a good starting point to
>> later let if be fixed up by actual balancing/tiering.
>>
>> It all sounds a bit hackish. :)
>>
> 
> It is a bit of a non-combo (Nonbo).  You're using weighted interleave
> with the intent of spreading out the bandwidth utilization (and maybe to
> offset some reclaim behavior? *shrug*) but then undo all the placement
> with tiering.

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.

> 
> But, in defense of the hackery - I have seen strategies like this work
> to optimize startup times and then let tiering optimize runtime.  Phased
> execution gets funky like that.

No doubt about that.

-- 
Cheers,

David