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

[Luiz Capitulino <luizcap@redhat.com>]

On 2025-04-16 12:32, Frank van der Linden wrote:
> 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.

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@redhat.com>

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