Re: [PATCH 1/2] mm/mempolicy: merge adjacent shared policy ranges

[Gregory Price (Meta)]

On 2026-11-13 22:36 +0100, David Hildenbrand (Arm) wrote:
> Shared policies can retain separate tree nodes for adjacent ranges with
> identical policies. This can create unnecessary policy ranges especially
> when individual VMAs cover individual file ranges, and user space sets
> the policy on these VMAs independently.
> 
> Extend the existing replacement handling to merge ranges with equal policy
> at either boundary. The existing replacement loop will then remove the old
> nodes and installs a single node for the combined range. This also avoids
> splitting an existing node when setting the same policy on a subrange.
> 
> Extending either boundary rules out splitting an existing node, so the
> allocation retry can only occur with the originally requested range.
> 
> This change will make it easier to cap the number of shared policy
> ranges per inode.
> 
> Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>

Reproduced some bad effects by setting a policy on every other page
shm policy across millions of pages - then setting a bunch of pages
individually to the same policy.

Base: merge never occurs, 1 range per page.
Patch: They all collapse back to a single range.

I was also able to reproduce a "BUG: soft lockup" when a file is freed
after creating millions of shm policies (absolutely not realistic).

I think this commit is probably fine to backport, but I agree it
doesn't seem worth it.

Have some thoughts about the limit in patch 2, but otherwise

Tested-by: Gregory Price (Meta) <gourry@xxxxxxxxxx>
Reviewed-by: Gregory Price (Meta) <gourry@xxxxxxxxxx>

-- 
~Gregory