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

[Li Zhe]

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.

>
>>   	/*
>>   	 * As we marked all tail pages with memblock_reserved_mark_noinit(),
>>   	 * we must initialize them ourselves here.
>>   	 */
>> -	for (pfn = head_pfn + start_page_number; pfn < end_pfn; page++, pfn++) {
>> -		__init_single_page(page, pfn, zone, nid);
>> -		prep_compound_tail(page, &folio->page, order);
>> -		set_page_count(page, 0);
>> -	}
>> +	pfn = head_pfn + start_page_number;
>> +
>> +	/*
>> +	 * Seed a template from the first real tail page and refresh only
>> +	 * PFN-dependent fields before copying it.
>> +	 */
>> +	__init_single_page(page, pfn, zone, nid);
>> +	prep_compound_tail(page, &folio->page, order);
>> +	set_page_count(page, 0);
>> +	memcpy(&template, page, sizeof(template));
> Do we need a separate template and page?
Yes. page is the first tail page that has already been initialized
normally. A separate template is needed so that later iterations can
refresh the PFN-dependent fields before memcpy_nontemporal() copies the
final state to each destination page.

Thanks for the review and the Ack.

Thanks,
Zhe

>
>> +
>> +	for (pfn++; pfn < end_pfn; pfn++)
>> +		memmap_init_page_from_template(pfn_to_page(pfn), pfn, zone,
>> +					       &template);
>>   }
>>   
>>   static void __init hugetlb_folio_init_vmemmap(struct folio *folio,
> Acked-by: Balbir Singh <balbirs@xxxxxxxxxx>