From: Sang-Heon Jeon <ekffu200098@gmail.com>
To: akpm@linux-foundation.org, Andreas Larsson <andreas@gaisler.com>,
"David S. Miller" <davem@davemloft.net>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Rich Felker <dalias@libc.org>,
Vlastimil Babka <vbabka@kernel.org>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Yury Norov <yury.norov@gmail.com>
Cc: linux-mm@kvack.org, Sang-Heon Jeon <ekffu200098@gmail.com>,
Brendan Jackman <jackmanb@google.com>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-sh@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
Nicholas Piggin <npiggin@gmail.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
sparclinux@vger.kernel.org,
Suren Baghdasaryan <surenb@google.com>, Zi Yan <ziy@nvidia.com>
Subject: [PATCH 0/4] treewide, mm: initialize node_possible_map like the other node maps
Date: Thu, 2 Jul 2026 02:18:47 +0900 [thread overview]
Message-ID: <20260701171851.2447626-1-ekffu200098@gmail.com> (raw)
While reviewing an earlier series [1], Andrew asked why we carefully
initialize node_possible_map at compile time, then zero it within __init
code anyway.
node_possible_map, aliased by node_states[N_POSSIBLE], is initialized to
NODE_MASK_ALL at compile time, unlike the other entries, which are
initialized with only node 0 set.
Architectures that use numa_memblks set node_possible_map from
numa_nodes_parsed, so the compile-time value is meaningless for them.
However, a few architectures that do not use numa_memblks do not set
node_possible_map on their own. Once these architectures set
node_possible_map to match their own topology, the NODE_MASK_ALL
initialization can be removed.
Patches 1-2 handle sparc64 and sh, which do not set node_possible_map
themselves. Both set node_online_map from their topology, so set
node_possible_map from node_online_map.
Patch 3 handles powerpc, which sets node_possible_map by intersecting it
with node_online_map. Nothing sets node_possible_map before this, so it is
still NODE_MASK_ALL and the intersection is just node_online_map. Once
patch 4 changes that initial value, the intersection would no longer be
node_online_map, so assign node_online_map directly.
Patch 4 initializes node_possible_map with only node 0 set, like the other
node_states[] entries. NODE_MASK_ALL is then no longer used, so remove it
and its only helper NODE_MASK_LAST_WORD.
[1] https://lore.kernel.org/all/20260624204030.3c8baa67713b6ca1d537baba@linux-foundation.org/
Sang-Heon Jeon (4):
sparc64: set node_possible_map in bootmem_init_numa()
sh: set node_possible_map in do_init_bootmem()
powerpc/numa: set node_possible_map from node_online_map
mm/page_alloc: initialize node_possible_map like the other node maps
arch/powerpc/mm/numa.c | 2 +-
arch/sh/mm/init.c | 2 ++
arch/sparc/mm/init_64.c | 2 ++
include/linux/nodemask.h | 20 --------------------
mm/page_alloc.c | 2 +-
5 files changed, 6 insertions(+), 22 deletions(-)
--
2.43.0
next reply other threads:[~2026-07-01 17:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 17:18 Sang-Heon Jeon [this message]
2026-07-01 17:18 ` [PATCH 1/4] sparc64: set node_possible_map in bootmem_init_numa() Sang-Heon Jeon
2026-07-01 17:18 ` [PATCH 2/4] sh: set node_possible_map in do_init_bootmem() Sang-Heon Jeon
2026-07-01 17:18 ` [PATCH 3/4] powerpc/numa: set node_possible_map from node_online_map Sang-Heon Jeon
2026-07-01 20:55 ` Yury Norov
2026-07-01 17:18 ` [PATCH 4/4] mm/page_alloc: initialize node_possible_map like the other node maps Sang-Heon Jeon
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=20260701171851.2447626-1-ekffu200098@gmail.com \
--to=ekffu200098@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andreas@gaisler.com \
--cc=chleroy@kernel.org \
--cc=dalias@libc.org \
--cc=davem@davemloft.net \
--cc=glaubitz@physik.fu-berlin.de \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mhocko@suse.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=sparclinux@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=ysato@users.sourceforge.jp \
--cc=yury.norov@gmail.com \
--cc=ziy@nvidia.com \
/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.