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

[Rakie Kim <rakie.kim@sk.com>]

On Tue, 18 Aug 2026 09:30:36 -0400 Gregory Price <gourry@gourry.net> wrote:

> 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.

I understand what you are concerned about, and I share the concern.

I tried to keep the addition minimal and to make it act only in the
intended situation: the filter runs in weighted interleave node
selection, only while the toggle is on. It does not change cpusets,
the zonelist, or the allocator fallback. Still, it is true that this
adds one more filtering layer to the constraints you listed.

I will try to organize this part so that it is as easy to follow as
possible, and reinforce the documentation as well. I am not sure that
will be enough, though - it needs more thought.

> 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.

This is something I think about a lot as well. Many users simply let
the policy use all nodes, and in the situation this series targets,
that is exactly what costs performance. To fix it, the kernel needs
more information than a nodemask carries. But as you pointed out,
adding that information also adds complexity. This is my concern as
well, and I think how to handle it needs a discussion.

Thanks again for your time and review.

Rakie Kim