Re: [PATCHv7 09/18] mm/hugetlb: Defer vmemmap population for bootmem hugepages

[David Hildenbrand (Arm)]

On 2/27/26 20:42, Kiryl Shutsemau (Meta) wrote:
> Currently, the vmemmap for bootmem-allocated gigantic pages is populated
> early in hugetlb_vmemmap_init_early(). However, the zone information is
> only available after zones are initialized. If it is later discovered
> that a page spans multiple zones, the HVO mapping must be undone and
> replaced with a normal mapping using vmemmap_undo_hvo().
> 
> Defer the actual vmemmap population to hugetlb_vmemmap_init_late(). At
> this stage, zones are already initialized, so it can be checked if the
> page is valid for HVO before deciding how to populate the vmemmap.
> 
> This allows us to remove vmemmap_undo_hvo() and the complex logic
> required to rollback HVO mappings.
> 
> In hugetlb_vmemmap_init_late(), if HVO population fails or if the zones
> are invalid, fall back to a normal vmemmap population.
> 
> Postponing population until hugetlb_vmemmap_init_late() also makes zone
> information available from within vmemmap_populate_hvo().

So we'll keep marking the sections as SECTION_IS_VMEMMAP_PREINIT such
that sparse_init_nid() will still properly skip it and leave population
to hugetlb_vmemmap_init_late().

Should we clear SECTION_IS_VMEMMAP_PREINIT in case we run into the
hugetlb_bootmem_page_zones_valid() scenario?

I suspect we don't care about SECTION_IS_VMEMMAP_PREINIT after boot and
can just leave the flag set. (maybe we wan to add a comment in the code?
above the vmemmap_populate() ?)

Nothing else jumped at me

Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>

-- 
Cheers,

David