Re: [PATCH v2 2/2] mm/page_alloc: refactor build_node_zonelist() out of build_zonelists()

[Gregory Price <gourry@gourry.net>]

On Mon, Sep 21, 2026 at 12:18:12PM -0400, Zi Yan wrote:
> On 20 Sep 2026, at 23:29, Gregory Price wrote:
> 
> OK, ZONELIST_PRIVATE and ZONELIST_KTEST are not upstream yet, right?
> In theory, the new zlidx can be added when you add new ZONELIST_ types.
> 
> I am OK with adding it now, but you could mention this change in
> the commit message to avoid confusion. Something like,
> for bulid_node_zonelist(), use ZONELIST_FALLBACK explicitly.
>
...
> > And add a BUILD_ON_BUG/ASSERT that forces any CONFIG_NUMA to have
> > balanced zonelist additions.
> 
> Got it. Thank you for the explanation. Are all combinations of
> {ZONELIST_FALLBACK, ZONELIST_PRIVATE, ZONELIST_KTEST} x
> {N_MEMORY_GENERAL, N_MEMORY, /* private only */} allowed?

Slight inaccuracy on the way zonelists are actually built.

Every node has a list in every zonelist.  The contents of each node's
list in that zonelist are limited to the candidate nodemask.

So consider the following nodes:  N0, N1, P2   (N=normal, P=private)

With the following candidate mappings:
   FALLBACK = N_MEMORY_GENERAL  (_COMMON)  (all normal nodes)
   PRIVATE  = N_MEMORY                     (all nodes)
   KTEST    = N_MEMORY & !N_MEMORY_GENERAL (only private nodes)

FALLBACK
  0  :  [0,1]
  1  :  [1,0]
  2  :  [0,1]  <- private node's fallback list is normal nodes

NOFALLBACK
  0  :  [0]
  1  :  [1]
  2  :  [2]

PRIVATE          Accessible via ALLOC_PRIVATE_ZONELIST
  0  :  [0,1,2]
  1  :  [1,0,2]
  2  :  [2,0,1]

PRIVATE_NOFALLBACK
  0  :  [0]
  1  :  [1]
  2  :  [2]

KTEST             Not accessible via any flag, completely isolated
  0  :  [2]
  1  :  [2]
  2  :  [2]

KTEST_NOFALLBACK  Not accessible via any flag, completely isolated
  0  :  []
  1  :  []
  2  :  [2]

I haven't posted the ktest series yet, but it's how i've made the page
allocator ktest-able.  Ktest is empowered to set the fallback list
directly rather than requiring a flag - not something any in-tree caller
can do - which lets it limit allocations to a private node and makes
mutations on the pgdat for that node deterministic from test-to-test.

Works on UML too, so testing is very fast. :]

Apologies for the added complexity in the explanation, but I figure it's
worth spelling out.

> Any enforcement if not? This is more related your “private node” series,
> instead of this patchset.
>

These zonelists aren't something we're going to allocate dynamically,
the enforcement is encoded in the function (build ZONELIST_X over
candidates N_MEMORY_Y).

> >
> > But I don't think it's strictly necessary for any of this, and we're
> > just shuffling code from one place to another.  Probably I can just add
> > that improvement when we add the next zonelist.  In the meantime - this
> > makes it easier to add new zonelists as-is (and just makes the code more
> > readable).
> 
> Sure, no rush.
> 
> Feel free to add
> 
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> 
> after you add some text on the added zlidx in the commit message.
> 

ack. hopefully the explanation above helps.

I will work that into the commit message in a reduced capacity.

~Gregory