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

[Luiz Capitulino]

On 2025-04-16 12:32, Frank van der Linden wrote:
> On Tue, Apr 15, 2025 at 6:08 PM Luiz Capitulino <luizcap@xxxxxxxxxx> 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.

Oh, thanks for the full explanation.

Since the new hugetlb init has to happen before sparse_init() then
this patch is fine by me and I appreciate your concern in not
changing/regressing the user visible behavior.

Reviewed-by: Luiz Capitulino <luizcap@xxxxxxxxxx>

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