Re: [PATCH 2/2] mm/hugetlb: optimize bootmem hugepage tail vmemmap init

[Mike Rapoport]

Hi,

On Mon, Nov 09, 2026 at 05:22:24PM +0800, Li Zhe wrote:
> On 11/9/26 11:01 AM, Li Zhe wrote:
> >
> > On 11/6/26 6:23 PM, Balbir Singh wrote:
> >> On Thu, Nov 05, 2026 at 08:06:15PM +0800, Li Zhe wrote:
> >>> Boot-time HugeTLB allocation has to initialize tail struct pages itself
> >>> when HugeTLB vmemmap optimization (HVO) is unavailable or fails.  For
> >>> gigantic pages, this can cover a large number of tail pages. Most state
> >>> installed by __init_single_page() and prep_compound_tail() is identical
> >>> for every tail page in the same huge page; only PFN-dependent fields
> >>> need refreshing.
> >>>
> >>> Initialize the first tail page normally, copy it into a local template,
> >>> then initialize the remaining tails from that template with
> >>> memmap_init_page_from_template().  This avoids repeatedly doing the 
> >>> full
> >>> __init_single_page() and prep_compound_tail() sequence for state 
> >>> that is
> >>> identical across tail pages in the same huge page.
> >>>
> >>> On an arm64 QEMU/KVM guest using 4K pages and 64 boot-time 1G hugepages
> >>> (HVO unavailable on arm64 in v7.4-rc1), the measured fallback tail
> >>> initialization time improved by 36.43%, measured with a temporary
> >>> jiffies-based printk modeled after the existing timing in
> >>> memmap_init_zone_device():
> >>>
> >>>    base:             318.4 ms
> >>>    with this patch:  202.4 ms
> >>>
> >>> Signed-off-by: Li Zhe <lizhe.67@xxxxxxxxxxxxx>
> >>> ---
> >>>   mm/hugetlb.c | 23 ++++++++++++++++++-----
> >>>   1 file changed, 18 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> >>> index da5d04edf7c1..987f16a5ea27 100644
> >>> --- a/mm/hugetlb.c
> >>> +++ b/mm/hugetlb.c
> >>> @@ -3219,19 +3219,32 @@ static void __init 
> >>> hugetlb_folio_init_tail_vmemmap(struct folio *folio,
> >>>       enum zone_type zone = folio_zonenum(folio);
> >>>       int nid = folio_nid(folio);
> >>>       struct page *page = folio_page(folio, start_page_number);
> >>> +    struct page template;
> >>>       unsigned long head_pfn = folio_pfn(folio);
> >>>       unsigned long pfn, end_pfn = head_pfn + end_page_number;
> >>>       unsigned int order = huge_page_order(h);
> >>>   +    if (start_page_number >= end_page_number)
> >>> +        return;
> >>> +
> >> Can this actually happen?
> >
> >
> > No, current callers always pass a non-empty range. I kept this to
> > preserve the old for-loop no-op semantics for an empty range, but it is
> > not needed here. I will remove it in v2.
> 
> 
> I need to correct this. A local Sashiko run pointed out that the bootmem
> fallback caller can pass an empty range on SuperH.
> 
> SuperH supports a 64M HugeTLB page size, and with 64K base pages
> pages_per_huge_page(h) is 1024. HUGETLB_VMEMMAP_RESERVE_PAGES is
> PAGE_SIZE / sizeof(struct page), which can also be 1024 or larger on a
> 32-bit SuperH configuration.

If the only difference is unnecessary initialization of the template on SuperH,
we don't care and you can drop that if.
 
> In that case the old for loop is a no-op. So I will keep the empty-range
> check in v2, before creating the seed template.
> 
> Thanks,
> Zhe

-- 
Sincerely yours,
Mike.