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

[David Hildenbrand (Arm)]

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?

-- 
Cheers,

David