Re: [PATCH v5 03/17] mm/mm_init: skip initializing shared vmemmap tail pages

[Muchun Song]

> On Sep 9, 2026, at 17:36, David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
> 
> On 8/25/26 10:45, Muchun Song wrote:
>> memmap_init_range() initializes every struct page in the target range.
>> For compound pages with vmemmap optimization, the tail struct pages are
>> backed by a shared vmemmap page.
>> 
>> Initializing those tail struct pages would overwrite the shared
>> vmemmap page contents, requiring users such as HugeTLB to restore the
>> metadata afterwards.
>> 
>> Track the compound order for HVO-backed sections and use that metadata
>> to detect struct pages that fall into the shared tail vmemmap range.
>> Skip those shared tail pages in memmap_init_range(), then initialize
>> pageblock migratetypes for the processed range with a helper after the
>> per-page initialization loop.
>> 
>> Keep direct mem_section access inside sparse helpers by exposing
>> pfn_to_section_order() to users that only need the order associated with
>> a PFN. This lets memmap_init_range() skip shared tail vmemmap pages
>> without exposing __pfn_to_section() to !SPARSEMEM builds.
>> 
>> This is a preparatory change for consolidating handling across users of
>> vmemmap optimization, and it also avoids redundant initialization of
>> shared tail vmemmap pages during early boot. That early-boot benefit
>> appears only once HugeTLB is switched to this common handling, since
>> HugeTLB is the early-boot user that creates those shared tail vmemmap
>> pages.
>> 
>> Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx>
>> ---
>> v5:
>> - Add comments for pageblock migratetype helper callers and shared
>>  tail vmemmap skipping (suggested by Mike Rapoport)
>> 
>> v4:
>> - Rename pfn_vmemmap_optimizable() to vmemmap_optimizable_pfn()
>>  for consistency with vmemmap_optimizable_order()
>> 
>> v3:
>> - Replace the !SPARSEMEM __pfn_to_section() stub with
>>  pfn_to_section_order() (suggested by Mike Rapoport)
>> 
>> v2:
>> - Fold section order tracking into the first user instead of keeping a
>>  standalone API-only patch (suggested by Mike Rapoport)
>> - Rename page_vmemmap_optimizable() to pfn_vmemmap_optimizable() and
>>  pass a PFN directly (suggested by Mike Rapoport)
>> - Initialize pageblock migratetypes from a helper after the per-page
>>  loop (suggested by Mike Rapoport)
>> - Use a 1G PFN chunk for cond_resched() in the pageblock helper
>>  (suggested by Mike Rapoport)
>> - Guard section_order() with CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP so
>>  it returns 0 when HVO is disabled and lets the compiler optimize the
>>  code as much as possible (suggested by Mike Rapoport)
>> - Explain why the !SPARSEMEM __pfn_to_section() stub belongs here
>>  (suggested by Mike Rapoport)
>> ---
>> include/linux/mmzone.h |  8 ++++++++
>> mm/mm_init.c           | 40 +++++++++++++++++++++++-----------------
>> mm/sparse.h            | 33 +++++++++++++++++++++++++++++++++
>> 3 files changed, 64 insertions(+), 17 deletions(-)
>> 
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index 5fb9b37819d5..df31cac12311 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -2022,6 +2022,14 @@ struct mem_section {
>> unsigned long section_mem_map;
>> 
>> struct mem_section_usage *usage;
>> +#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
>> + /*
>> + * Normally, sections hold regular (order-0) pages. However, for
>> + * sections with HVO enabled, this tracks the compound page order
>> + * to enable deduplication of redundant vmemmap pages.
>> + */
>> + unsigned int order;
> 
> order is a way too generic name for this. page_order? compound_page_order?

compound_page_order is more accurate. I think it is more suitable.

Thanks.

> 
> -- 
> Cheers,
> 
> David