Re: [PATCH] mm/hugetlb: use separate nodemask for bootmem allocations

[Frank van der Linden <fvdl@google.com>]

On Tue, Apr 15, 2025 at 6:08 PM Luiz Capitulino <luizcap@redhat.com> wrote:
>
> On 2025-04-02 16:56, Frank van der Linden wrote:
> > Hugetlb boot allocation has used online nodes for allocation since
> > commit de55996d7188 ("mm/hugetlb: use online nodes for bootmem
> > allocation"). This was needed to be able to do the allocations
> > earlier in boot, before N_MEMORY was set.
>
> Honest question: I imagine there's a reason why we can't move
> x86's hugetlb_cma_reserve() and hugetlb_bootmem_alloc() calls
> in setup_arch() to after x86_init.paging.pagetable_init() (which
> seems to be where we call zone_sizes_init())? This way we could
> go back to using N_MEMORY and avoid this dance.
>
> I'm not familiar with vmemmap if that's the reason...
>

Yeah, vmemmap is the reason. pre-HVO (setting up vmemmap HVO-style)
requires the hugetlb bootmem allocations to be done before
sparse_init(), so the ordering you propose wouldn't work.

I originally looked at explicitly initializing N_MEMORY earlier,
figuring that all that was needed was having memblock node information
available. But there seems to be a history there - N_MEMORY indicates
that buddy allocator memory is available on the node, and several
comments referenced the fact that zone init and rounding may end up
not setting N_MEMORY on NUMA nodes with a tiny amount of memory. There
is also code that sets N_MEMORY temporarily in
find_zone_movable_pfns_for_nodes().

Some of the commits went back a long time ago, and I can't quite judge
if the comments still apply without looking at the code more. So, I
chickened out, and did a hugetlb only change to fix the hugetlb
issues.

But it does seem like setting N_MEMORY can be cleaned up a bit, it's
definitely something to follow up on.

- Frank