Re: [PATCH v3 0/2] mm: optimize HugeTLB bootmem hugepage init

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

On 11/13/26 12:34 AM, Mike Rapoport wrote:
> Hi,
>
> On Thu, Nov 12, 2026 at 07:28:14PM +0800, Li Zhe wrote:
>> This series speeds up the fallback initialization path for HugeTLB tail
>> struct pages during boot-time hugepage allocation, when HugeTLB vmemmap
>> optimization (HVO) is unavailable or fails.
>>
>> Patch 1 factors the PFN-dependent template refresh from the ZONE_DEVICE
>> template-copy path into memmap_init_refresh_pfn_fields().  The
>> ZONE_DEVICE path keeps its memcpy_nontemporal() copy primitive.
>>
>> Patch 2 adds a HugeTLB-specific copy helper in
>> hugetlb_folio_init_tail_vmemmap(): initialize the first tail page
>> normally, then initialize the remaining tail pages by copying that page
>> with memcpy() and refreshing only PFN-dependent fields in the destination
>> page.
>>
>> Tested on a v7.4-rc2 base with 4K base pages and 64 boot-time 1G
>> hugepages, measured with a temporary jiffies-based printk.  HVO is
>> unavailable on arm64; on x86-64, hugetlb_free_vmemmap=off was used to
>> exercise the fallback path.
>>
>>    arch    base      with this patch  reduction
>>    arm64   360.8 ms  256.0 ms         29.05%
>>    x86-64  171.0 ms  165.0 ms          3.51%
> Thanks for the numbers!
>   
> The changes are fine, but since they are going to be merged into Muchun's
> series, I'll wait for that for the detailed review.


Thanks Mike.

Muchun, thanks for integrating these patches into your series.

Thanks,
Zhe

>
>> Li Zhe (2):
>>    mm/mm_init: factor out memmap_init_refresh_pfn_fields()
>>    mm/hugetlb: optimize bootmem hugepage tail vmemmap init
>>
>>   mm/hugetlb.c | 23 ++++++++++++++++++-----
>>   mm/mm_init.c | 11 ++++++-----
>>   mm/mm_init.h | 11 +++++++++++
>>   3 files changed, 35 insertions(+), 10 deletions(-)