Re: [PATCH v5 04/17] mm/sparse-vmemmap: initialize shared tail vmemmap pages on allocation

[Muchun Song <muchun.song@linux.dev>]

> On Sep 9, 2026, at 17:39, David Hildenbrand (Arm) <david@kernel.org> wrote:
> 
> On 8/25/26 10:45, Muchun Song wrote:
>> The shared tail vmemmap page allocated in vmemmap_get_tail() used to be
>> left uninitialized, because memmap_init_range() would later overwrite
>> it.  That forced users such as HugeTLB to defer the initialization to
>> their own setup paths.
>> 
>> Now that memmap_init_range() skips shared tail vmemmap pages, initialize
>> them immediately in vmemmap_get_tail() with init_compound_tail()
>> instead.
>> 
>> This moves the initialization to the point where the shared tail page is
> 
> You are not really moving the initialization? I see a new initialization being
> added but none getting removed.
> 
> Wouldn't hugetlb_bootmem_struct_page_init() have to be updated as well (as the
> comment you are changing indicates) or what am I missing?

Strictly speaking, this patch adds initialization rather than removing it.

I used "moves" from a logical perspective: the initialization responsibility
now shifts to the allocation point (vmemmap_get_tail()), making the HugeTLB
side redundant. But since this is a preparatory patch (the section order field
isn't set yet, so the skip logic introduced in patch 3 doesn't take effect —
meaning the tail page would still be overwritten in memmap_init_range()), the
old code cannot be removed yet. It is cleaned up in the follow-up once the
switch is complete.

Thanks,
Muchun

> 
> --
> Cheers,
> 
> David