Re: [PATCH 0/4] mm/mempolicy: introduce package-aware weighted interleave

[Gregory Price <gourry@gourry.net>]

On Tue, Aug 18, 2026 at 03:01:58PM +0900, Rakie Kim wrote:
> On Mon, 17 Aug 2026 12:19:51 -0400 Gregory Price <gourry@gourry.net> wrote:
> 
> > I have some concerns with the now additional filtering mechanism
> > introdced into the allocation stack, but fundamentally I think this is
> > a *better* solution than a straight weight-matrix.
> 
> About the cost of the filter: when the toggle is off, the filter does
> not run. When it is on, node selection needs a nodemask filtering
> step, but in my tests the overhead was negligible. I will look at
> this part further and check whether there is more room to optimize.
> 

Not concerned about the performance, concerned about how complicated the
mempolicy - cgroup - zonelist - page_alloc interaction already is, and
then adding another filtering mechanism on top.

Today we have:

1) cpuset constrains mempolicy (nodemask remaps)
2) cpuset constrains zonelist walks
3) mempolicy nodemask constrains zonelist walks
4) memory-tiers.c nodemask constrains zonelist walks for demotion
5) zonelist membership constrains allocation access
6) a bunch of corner conditions that violate 1-3 for the sake of forward
   progress

now we're adding:

7) memory-tiers.c nodemask constrains mempolicy nodemask
   except when it doesn't, because fallbacks occurred hard enough

It's already un-intuitive how and when memory lands on certain nodes.

To be clear, I'm not saying this idea is bad - either as-is or in some
other form - just that adding another nodemask filtering path is making
it harder and harder to understand what lands where.

Mostly starting to wonder if we're reaching the point where the page
allocator needs to take something a little more descriptive than a
nodemask to dictate placement.

~Gregory