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

[Muchun Song]

> On Nov 11, 2026, at 19:24, Li Zhe <lizhe.67@xxxxxxxxxxxxx> wrote:
> 
> 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@xxxxxxxxxx/
>>> 
>>> 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?

Sure.

Thanks.

> 
> 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@xxxxxxxxxxxxx/#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