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

[sashiko-bot@kernel.org]

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.

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