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

[Zi Yan]

On 21 Sep 2026, at 12:38, Gregory Price wrote:

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

Got it. It makes sense to me now. Thanks.

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

Definitely. Great information.

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

ack.
>
>>>
>>> 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@xxxxxxxxxx>
>>
>> after you add some text on the added zlidx in the commit message.
>>
>
> ack. hopefully the explanation above helps.

Yep. :)

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

To be clear, I just would like you to mention the addition of
zlidx to bulid_node_zonelist(). Thanks.

Best Regards,
Yan, Zi