From: Mike Rapoport <rppt@kernel.org>
To: Li Zhe <lizhe.67@bytedance.com>
Cc: akpm@linux-foundation.org, apopple@nvidia.com,
balbirs@nvidia.com, david@kernel.org, muchun.song@linux.dev,
osalvador@suse.de, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v2 0/2] mm: optimize HugeTLB bootmem hugepage init
Date: Wed, 11 Nov 2026 10:12:30 +0200 [thread overview]
Message-ID: <avQjbt-QUp-W3_9v@kernel.org> (raw)
In-Reply-To: <20261110114859.76343-1-lizhe.67@bytedance.com>
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.
> 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
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2026-11-11 8:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 11:48 [PATCH v2 0/2] mm: optimize HugeTLB bootmem hugepage init Li Zhe
2026-11-10 11:48 ` [PATCH v2 1/2] mm/mm_init: factor out memmap_init_page_from_template() Li Zhe
2026-11-11 7:58 ` Muchun Song
2026-11-10 11:48 ` [PATCH v2 2/2] mm/hugetlb: optimize bootmem hugepage tail vmemmap init Li Zhe
2026-11-10 13:35 ` sashiko-bot
2026-11-11 3:14 ` Li Zhe
2026-11-11 5:28 ` Muchun Song
2026-11-11 7:57 ` Li Zhe
2026-11-11 8:16 ` Mike Rapoport
2026-11-11 8:21 ` Muchun Song
2026-11-11 8:14 ` Mike Rapoport
2026-11-11 8:12 ` Mike Rapoport [this message]
2026-11-11 11:24 ` [PATCH v2 0/2] mm: optimize HugeTLB bootmem hugepage init Li Zhe
2026-11-11 11:37 ` Muchun Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=avQjbt-QUp-W3_9v@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=balbirs@nvidia.com \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizhe.67@bytedance.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.