On 2023/2/14 19:58, David Hildenbrand wrote:
On 14.02.23 12:48, David Hildenbrand wrote:
On 14.02.23 12:44, Mike Rapoport wrote:
(added x86 folks)
On Tue, Feb 14, 2023 at 12:29:42PM +0100, David Hildenbrand wrote:
On 14.02.23 12:26, Qi Zheng wrote:
On 2023/2/14 19:22, David Hildenbrand wrote:
TBH, this is the first time I hear of NODE_MIN_SIZE and it seems
to be a
pretty x86 specific thing.
Are we sure we want to get NODE_MIN_SIZE involved?
Maybe add an arch_xxx() to handle it?
I still haven't figured out what we want to achieve with
NODE_MIN_SIZE at
all. It smells like an arch-specific hack looking at
"Don't confuse VM with a node that doesn't have the minimum amount of
memory"
Why shouldn't mm-core deal with that?
Well, a node with <4M RAM is not very useful and bears all the
overhead of
an extra live node.
And totally not with 4.1M, haha.
I really like the "Might fix boot" in the commit description.
But, hey, why won't we just drop that '< NODE_MIN_SIZE' and let
people with
weird HW configurations just live with this?
;)
Actually, remembering 09f49dca570a ("mm: handle uninitialized numa nodes
gracefully"), this might be the right thing to do. That commit assumes
that all offline nodes would get the pgdat allocated in
free_area_init(). So that we end up with an allocated pgdat for all
Can also See commit 1ca75fa7f19d ("arch/x86/mm/numa: Do not initialize
nodes twice"). The commit message explains the initialization process
more clearly, it may be helpful. :)
possible nodes. The reasoning IIRC was that we don't care about wasting
memory in weird VM setups.
CCing Michal.
--
Thanks,
Qi
