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

["Li Zhe" <lizhe.67@bytedance.com>]

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@bytedance.com>
>>>>> ---
>>>>>    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.

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