From: "Zi Yan" <ziy@nvidia.com>
To: "Gregory Price" <gourry@gourry.net>, <linux-mm@kvack.org>
Cc: <linux-kernel@vger.kernel.org>, <kernel-team@meta.com>,
<akpm@linux-foundation.org>, <david@kernel.org>, <ljs@kernel.org>,
<liam@infradead.org>, <vbabka@kernel.org>, <rppt@kernel.org>,
<surenb@google.com>, <mhocko@suse.com>,
<brendan.jackman@linux.dev>, <hannes@cmpxchg.org>
Subject: Re: [PATCH v2 2/2] mm/page_alloc: refactor build_node_zonelist() out of build_zonelists()
Date: Sun, 20 Sep 2026 22:53:13 -0400 [thread overview]
Message-ID: <DLKNKTQHSA6H.6XC9WV37LSVR@nvidia.com> (raw)
In-Reply-To: <DLKNHNP6LH59.3MEEBCAJGFEVK@nvidia.com>
On Sun Sep 20, 2026 at 10:49 PM EDT, Zi Yan wrote:
> On Fri Sep 11, 2026 at 11:04 PM EDT, Gregory Price wrote:
>> Extract per-node fallback-list construction into build_node_zonelist().
>> Build each selected node directly into the destination zonelist so no
>> intermediate node_order array or node count is needed. Print the fallback
>> order as each node is added.
>>
>> This lets us build new zonelists from candidate nodemasks instead of just
>> the default N_MEMORY node state list.
>>
>> No functional change: build_zonelists() builds and prints the same FALLBACK
>> list over N_MEMORY with node_load updates as before.
>>
>> Signed-off-by: Gregory Price <gourry@gourry.net>
>> ---
>> mm/page_alloc.c | 63 ++++++++++++++++++-------------------------------
>> 1 file changed, 23 insertions(+), 40 deletions(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 7efce139d562..d1888d5630e0 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -5857,31 +5857,6 @@ int find_next_best_node_in(int node, nodemask_t *used_node_mask,
>> }
>>
>>
>> -/*
>> - * Build zonelists ordered by node and zones within node.
>> - * This results in maximum locality--normal zone overflows into local
>> - * DMA zone, if any--but risks exhausting DMA zone.
>> - */
>> -static void build_zonelists_in_node_order(pg_data_t *pgdat, int *node_order,
>> - unsigned nr_nodes)
>> -{
>> - struct zoneref *zonerefs;
>> - int i;
>> -
>> - zonerefs = pgdat->node_zonelists[ZONELIST_FALLBACK]._zonerefs;
>> -
>> - for (i = 0; i < nr_nodes; i++) {
>> - int nr_zones;
>> -
>> - pg_data_t *node = NODE_DATA(node_order[i]);
>> -
>> - nr_zones = build_zonerefs_node(node, zonerefs);
>> - zonerefs += nr_zones;
>> - }
>> - zonerefs->zone = NULL;
>> - zonerefs->zone_idx = 0;
>> -}
>> -
>> /*
>> * Build __GFP_THISNODE zonelists
>> */
>> @@ -5897,20 +5872,24 @@ static void build_thisnode_zonelists(pg_data_t *pgdat)
>> zonerefs->zone_idx = 0;
>> }
>>
>> -static void build_zonelists(pg_data_t *pgdat)
>> +/*
>> + * Build one zonelist ordered by node and zones within node. This results in
>> + * maximum locality--normal zone overflows into local DMA zone, if any--but
>> + * risks exhausting DMA zone.
>> + */
>> +static void build_node_zonelist(pg_data_t *pgdat, const nodemask_t *candidates,
>> + int zlidx)
Is build_numa_aware_zonelist() a better name? Since the old comment said
"NUMA-aware ording of nodes" and the code uses find_next_best_node_in().
>> {
>> - static int node_order[MAX_NUMNODES];
>> - int node, nr_nodes = 0;
>> + struct zoneref *zonerefs = pgdat->node_zonelists[zlidx]._zonerefs;
>
> Why does build_node_zonelist() need to have a new zlidx instead of using
> ZONELIST_FALLBACK like build_zonelists_in_node_order() did?
>
>> nodemask_t used_mask = NODE_MASK_NONE;
>> - int local_node, prev_node;
>> + int local_node = pgdat->node_id;
>> + int prev_node = local_node;
>> + int node;
>>
>> - /* NUMA-aware ordering of nodes */
>> - local_node = pgdat->node_id;
>> - prev_node = local_node;
>> + pr_info("Fallback order for Node %d: ", local_node);
>>
>> - memset(node_order, 0, sizeof(node_order));
>> while ((node = find_next_best_node_in(local_node, &used_mask,
>> - &node_states[N_MEMORY])) >= 0) {
>> + candidates)) >= 0) {
>> /*
>> * We don't want to pressure a particular node.
>> * So adding penalty to the first node in same
>> @@ -5920,18 +5899,22 @@ static void build_zonelists(pg_data_t *pgdat)
>> node_distance(local_node, prev_node))
>> node_load[node] += 1;
>>
>> - node_order[nr_nodes++] = node;
>> + zonerefs += build_zonerefs_node(NODE_DATA(node), zonerefs);
>> + pr_cont("%d ", node);
>> prev_node = node;
>> }
>>
>> - build_zonelists_in_node_order(pgdat, node_order, nr_nodes);
>> - build_thisnode_zonelists(pgdat);
>> - pr_info("Fallback order for Node %d: ", local_node);
>> - for (node = 0; node < nr_nodes; node++)
>> - pr_cont("%d ", node_order[node]);
>> + zonerefs->zone = NULL;
>> + zonerefs->zone_idx = 0;
>> pr_cont("\n");
>> }
>>
>> +static void build_zonelists(pg_data_t *pgdat)
>> +{
>> + build_node_zonelist(pgdat, &node_states[N_MEMORY], ZONELIST_FALLBACK);
>> + build_thisnode_zonelists(pgdat);
>
> If build_thisnode_zonelists() means ZONELIST_NOFALLBACK, why
> cannot build_node_zonelist() imply ZONELIST_FALLBACK?
>
>> +}
>> +
>> #ifdef CONFIG_HAVE_MEMORYLESS_NODES
>> /*
>> * Return node id of node used for "local" allocations.
--
Best Regards,
Yan, Zi
next prev parent reply other threads:[~2026-09-21 2:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-12 3:04 [PATCH v2 0/2] mm: refactor zonelist constructors and iterators Gregory Price
2026-09-12 3:04 ` [PATCH v2 1/2] mm: refactor find_next_best_node to find_next_best_node_in Gregory Price
2026-09-14 15:00 ` Zi Yan
2026-09-18 20:42 ` David Hildenbrand (Arm)
2026-09-18 21:49 ` Gregory Price
2026-09-12 3:04 ` [PATCH v2 2/2] mm/page_alloc: refactor build_node_zonelist() out of build_zonelists() Gregory Price
2026-09-14 14:56 ` Vlastimil Babka (SUSE)
2026-09-14 15:04 ` Gregory Price
2026-09-21 2:49 ` Zi Yan
2026-09-21 2:53 ` Zi Yan [this message]
2026-09-21 3:33 ` Gregory Price
2026-09-21 16:20 ` Zi Yan
2026-09-21 3:29 ` Gregory Price
2026-09-21 16:18 ` Zi Yan
2026-09-21 16:38 ` Gregory Price
2026-09-21 17:04 ` Gregory Price
2026-09-21 17:18 ` Zi Yan
2026-09-21 23:58 ` Zi Yan
2026-09-22 1:02 ` Gregory Price
2026-09-15 16:27 ` [PATCH v2 0/2] mm: refactor zonelist constructors and iterators Zenghui Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DLKNKTQHSA6H.6XC9WV37LSVR@nvidia.com \
--to=ziy@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=brendan.jackman@linux.dev \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@meta.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.