Re: [PATCH v2 02/14] mm/hugetlb: optimize bootmem hugepage tail vmemmap init

[Muchun Song <muchun.song@linux.dev>]

> On Nov 13, 2026, at 12:07, sashiko-bot@kernel.org wrote:
> 
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue to consider:
> - [Low] mm/hugetlb: commit message mismatches
>  memmap_init_page_from_template()
> --
> 
> commit 7cc97c08b2296fc2518d9ae6da5950cb731c48eb
> Author: Li Zhe <lizhe.67@bytedance.com>
> 
> mm/hugetlb: optimize bootmem hugepage tail vmemmap init
> 
> This commit speeds up boot-time HugeTLB tail page vmemmap initialization
> by seeding a template from the first tail page and initializing the
> remaining tail pages with memmap_init_page_from_template().
> 
>> Initialize the first tail page normally, then initialize the remaining
>> tails with hugetlb_init_tail_page().  This copies the already
>> initialized first tail page with memcpy() and refreshes only the
>> PFN-dependent fields in the destination page, while avoiding the full
>> __init_single_page() and prep_compound_tail() sequence for state that is
>> identical across tail pages in the same huge page.
> 
> [Severity: Low]
> This isn't a bug, but the commit message appears to describe an earlier
> version of the patch.  hugetlb_folio_init_tail_vmemmap() copies the first
> tail page into a stack template and calls memmap_init_page_from_template()
> (which refreshes the template before copying) rather than a
> hugetlb_init_tail_page() helper.  The commit message also omits the change
> in memmap_init_page_from_template() that restricts memcpy_nontemporal() to
> ZONE_DEVICE pages and uses memcpy() for other zones.

My bad. I forgot to update the commit message, the corrected commit message
is as follows:

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, so repeating the full
initialization sequence for each tail page is unnecessary.

Initialize the first tail page normally and use it as a template for the
remaining tail pages.  Before each copy,
memmap_init_page_from_template() refreshes the PFN-dependent fields in
the template, avoiding repeated initialization of state shared by all
tail pages.

This extends memmap_init_page_from_template() from ZONE_DEVICE to normal
memory.  Keep memcpy_nontemporal() for ZONE_DEVICE pages and use
memcpy() for pages in other zones.  memcpy_nontemporal() was also tested
for the HugeTLB path, but did not provide a similar benefit; on x86-64,
memcpy() performed better for this workload.

The fallback path was measured on a v7.4-rc2 base with a temporary
jiffies-based printk modeled after the existing timing in
memmap_init_zone_device(), using 4K base pages and 64 boot-time 1G
hugepages.  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%

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20261113033442.62970-1-songmuchun@bytedance.com?part=2