On Tue, Aug 18, 2026 at 03:01:58PM +0900, Rakie Kim wrote: > On Mon, 17 Aug 2026 12:19:51 -0400 Gregory Price <[email protected]> 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
