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

[Mike Rapoport]

On Mon, Nov 09, 2026 at 05:52:19PM +0800, Li Zhe wrote:
> On 11/9/26 5:41 PM, Mike Rapoport wrote:
> > 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.
> 
> It is not only initializing the local template. The code first
> initializes one page with __init_single_page(), prep_compound_tail(),
> and set_page_count(), and then copies that page into the template.
> 
> So if start_page_number == end_page_number == pages_per_huge_page(h),
> the old loop is a no-op, but without the check the new code would update
> folio_page(folio, start_page_number), which is outside the HugeTLB
> folio.

A recent patch to arch/sh indicated that hugetlb is never used on sh:

https://lore.kernel.org/linux-mm/auJI2blzfpFD9yLe@xxxxxxxxxx/

And it seems none of upstream sh defconfigs can hit it.
 
> Thanks,
> Zhe
> 
> >   
> >> 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.