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

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

On 11/11/26 4:12 PM, Mike Rapoport wrote:
> Hi,
>
> On Tue, Nov 10, 2026 at 07:48:57PM +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 existing ZONE_DEVICE template-copy operation into
>> memmap_init_page_from_template().
>>
>> Patch 2 reuses that helper in hugetlb_folio_init_tail_vmemmap():
>> initialize the first tail page normally, copy it into a local template,
>> then initialize the remaining tail pages by refreshing only PFN-dependent
>> fields before copying the template.
>>
>> In the earlier discussion, Mike asked whether the same kind of
>> template-based initialization also helps the ordinary struct page
>> initialization path:
>>
>> https://lore.kernel.org/all/akfB6Qe-jKDEMUxz@kernel.org/
>>
>> I tested that direction as well, but did not see a measurable benefit
>> for ordinary struct page initialization. The measurable improvement I
>> could find is in the HugeTLB bootmem hugepage tail path, where gigantic
>> pages can require initializing a large number of tail struct pages when
>> HVO does not cover the allocation.
>>
>> Tested on an arm64 QEMU/KVM guest with 4K base pages and 64 boot-time 1G
>> hugepages. HVO is unavailable on arm64 in v7.4-rc1, so the fallback tail
>> initialization path is exercised.
>>
>> Results averaged over five boots, measured with a temporary
>> jiffies-based printk:
>>
>>    base (v7.4-rc1):  318.4 ms
>>    with this patch:  202.4 ms
> Are there numbers for x86 without HVO as well?
> We need to be sure this does not regress that use case.


Thanks for the feedback.

I did some additional x86 testing today, but the result was different
from the similar x86 test I did earlier on linux-7.2-rc1. After
replacing memcpy_nontemporal() with regular memcpy(), the result looked
better. I need to re-check the old test code, since I may have mixed up
which copy primitive was used there.

Muchun, could you please hold off folding this series into your patchset
until I send v3?

Thanks,
Zhe

>   
>> This is a 36.43% reduction in the measured fallback tail initialization
>> time. The temporary measurement instrumentation is not part of this
>> series.
>>
>> Li Zhe (2):
>>    mm/mm_init: factor out memmap_init_page_from_template()
>>    mm/hugetlb: optimize bootmem hugepage tail vmemmap init
>>
>>   mm/hugetlb.c | 20 +++++++++++++++-----
>>   mm/mm_init.c | 34 ++++++++++++++++++++--------------
>>   mm/mm_init.h |  2 ++
>>   3 files changed, 37 insertions(+), 19 deletions(-)
>>
>> ---
>> v1: https://lore.kernel.org/all/20261105120615.16817-1-lizhe.67@bytedance.com/#t
>>
>> Changes in v2:
>> - Add a comment for the template-before-copy ordering, as suggested by
>>    Muchun Song.
>> - Drop the empty-range guard in hugetlb_folio_init_tail_vmemmap()
>>    as suggested by Balbir Singh and Mike Rapoport; current callers are
>>    expected to pass a non-empty range.
>>
>> -- 
>> 2.20.1