From: Muchun Song <muchun.song@linux.dev>
To: Muchun Song <songmuchun@bytedance.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>, Michal Hocko <mhocko@suse.com>,
David Laight <david.laight.linux@gmail.com>,
"Liam R . Howlett" <liam@infradead.org>,
Suren Baghdasaryan <surenb@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 00/17] mm: Introduce section-based vmemmap optimization for HugeTLB
Date: Wed, 19 Aug 2026 19:30:15 +0800 [thread overview]
Message-ID: <BDDE93CF-876C-4A65-A4F7-C717CDCE61F4@linux.dev> (raw)
In-Reply-To: <20260819095140.17252-1-songmuchun@bytedance.com>
> On Aug 19, 2026, at 17:51, Muchun Song <songmuchun@bytedance.com> wrote:
>
> This series is split out from the earlier, larger series "mm: Generalize
> HVO for HugeTLB and device DAX" [1]. While the parent series generalizes
> vmemmap optimization across HugeTLB and device DAX, this subset addresses
> a single, self-contained step: making the generic sparse-vmemmap code
> section-based optimization aware and switching HugeTLB bootmem pages to
> this path.
>
> HugeTLB vmemmap optimization currently has its own early boot setup
> path. It pre-populates optimized vmemmap mappings before the normal
> sparse-vmemmap population code runs, and sparsemem carries
> SPARSEMEM_VMEMMAP_PREINIT only to support that special case.
>
> That makes the HugeTLB vmemmap optimization path harder to share with
> other users of sparse-vmemmap optimization and leaves a fair amount of
> HugeTLB-specific boot-time state in the generic memory initialization
> flow.
>
> This series introduces section-based vmemmap optimization support in
> the sparse-vmemmap code and switches HugeTLB bootmem pages over to it.
> Instead of having HugeTLB pre-populate optimized vmemmap mappings
> itself, HugeTLB now records the compound page order in the corresponding
> memory sections. The generic sparse-vmemmap population path can then
> allocate or reuse shared tail vmemmap pages based on section metadata.
>
> The patches are organized as follows:
>
> - patches 1-2 prepare sparsemem and vmemmap optimization metadata
> - patches 3-8 teach the common sparse-vmemmap paths to use that state
> - patches 9-10 switch HugeTLB bootmem optimization to the
> section-based path
> - patches 11-17 clean up sparsemem and HugeTLB bootmem code that is no
> longer needed after the conversion
>
> This is intended to be the second smaller step toward the broader HVO
> generalization. The device DAX conversion and the wider HVO
> consolidation are left for follow-up series.
I've confirmed that all the reports from Sashiko are false positives in
this version, and they also appeared as duplicates in the previous one.
Thanks.
>
> v4:
> - Rename pfn_vmemmap_optimizable() to vmemmap_optimizable_pfn() for
> consistency with vmemmap_optimizable_order().
> - Move section_nr_vmemmap_pages() outside CONFIG_MEMORY_HOTPLUG to fix
> CONFIG_MEMORY_HOTPLUG=n builds (reported by kernel test robot).
>
> v3:
> - Replaced the !SPARSEMEM __pfn_to_section() stub with
> pfn_to_section_order() so callers can keep mem_section access inside
> sparse helpers (suggested by Mike Rapoport).
> - Added vmemmap_optimizable_order() for order-based vmemmap
> optimization checks and used it for HugeTLB bootmem decisions.
> - Fixed the pfn_to_zone() commit message to name mm/mm_init.h instead
> of mm/internal.h.
> - Collected Acked-by tags from Mike Rapoport.
>
> v2:
> - Kept struct mem_section aligned after relaxing lookup constraints
> (suggested by David Laight).
> - Folded section order tracking into the first user instead of keeping
> a standalone API-only patch (suggested by Mike Rapoport).
> - Renamed the HVO order macros with a VMEMMAP_OPTIMIZATION prefix
> (suggested by Mike Rapoport).
> - Moved pfn_to_zone() before the sparse-vmemmap optimization changes
> (suggested by Mike Rapoport).
> - Kept vmemmap accounting and population logic in sparse-vmemmap.c
> (suggested by Mike Rapoport).
> - Renamed the early sparsemem helper to sparse_sections_init()
> (suggested by Mike Rapoport).
> - Fixed the !SPARSEMEM stub name so SPARSEMEM=n builds compile
> (reported by Sashiko).
> - Guarded section_order() with CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP so
> it returns 0 when HVO is disabled and lets the compiler optimize the
> code as much as possible (suggested by Mike Rapoport).
> - Collected Acked-by tags from Mike Rapoport.
>
> [1] https://lore.kernel.org/linux-mm/20260513130542.35604-1-songmuchun@bytedance.com/
>
> Muchun Song (17):
> mm/sparse: relax struct mem_section size constraints
> mm/sparse-vmemmap: rename HVO order macros
> mm/mm_init: skip initializing shared vmemmap tail pages
> mm/sparse-vmemmap: initialize shared tail vmemmap pages on allocation
> mm/sparse-vmemmap: support section-based vmemmap accounting
> mm/mm_init: factor out pfn_to_zone()
> mm/sparse-vmemmap: move vmemmap_get_tail() before PTE population
> mm/sparse-vmemmap: support section-based vmemmap optimization
> mm/sparse: initialize memory sections earlier
> mm/hugetlb: switch HugeTLB to section-based vmemmap optimization
> mm/sparse-vmemmap: remove SPARSEMEM_VMEMMAP_PREINIT support
> mm/sparse: inline usemap allocation into sparse_init_nid()
> mm/sparse: remove section_map_size()
> mm/hugetlb: remove HUGE_BOOTMEM_HVO
> mm/hugetlb: remove HUGE_BOOTMEM_CMA
> mm/hugetlb: localize struct huge_bootmem_page
> mm/hugetlb: localize HUGE_BOOTMEM_ZONES_VALID
>
> arch/x86/Kconfig | 1 -
> fs/Kconfig | 1 -
> include/linux/hugetlb.h | 5 -
> include/linux/mm.h | 4 -
> include/linux/mmzone.h | 66 ++++--------
> mm/Kconfig | 5 -
> mm/hugetlb.c | 64 ++++--------
> mm/hugetlb_vmemmap.c | 103 +------------------
> mm/hugetlb_vmemmap.h | 13 +--
> mm/internal.h | 7 --
> mm/mm_init.c | 63 +++++++-----
> mm/mm_init.h | 1 +
> mm/sparse-vmemmap.c | 216 ++++++++++++++++++----------------------
> mm/sparse.c | 94 ++++-------------
> mm/sparse.h | 85 ++++++++++++++++
> scripts/gdb/linux/mm.py | 6 +-
> 16 files changed, 285 insertions(+), 449 deletions(-)
>
>
> base-commit: 5453bc3279e9f8578ac3e534d476240e40c879e1
> --
> 2.54.0
>
prev parent reply other threads:[~2026-08-19 11:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 9:51 [PATCH v4 00/17] mm: Introduce section-based vmemmap optimization for HugeTLB Muchun Song
2026-08-19 9:51 ` [PATCH v4 01/17] mm/sparse: relax struct mem_section size constraints Muchun Song
2026-08-19 9:51 ` [PATCH v4 02/17] mm/sparse-vmemmap: rename HVO order macros Muchun Song
2026-08-19 9:51 ` [PATCH v4 03/17] mm/mm_init: skip initializing shared vmemmap tail pages Muchun Song
2026-08-19 9:51 ` [PATCH v4 04/17] mm/sparse-vmemmap: initialize shared tail vmemmap pages on allocation Muchun Song
2026-08-19 9:51 ` [PATCH v4 05/17] mm/sparse-vmemmap: support section-based vmemmap accounting Muchun Song
2026-08-19 9:51 ` [PATCH v4 06/17] mm/mm_init: factor out pfn_to_zone() Muchun Song
2026-08-19 9:51 ` [PATCH v4 07/17] mm/sparse-vmemmap: move vmemmap_get_tail() before PTE population Muchun Song
2026-08-19 9:51 ` [PATCH v4 08/17] mm/sparse-vmemmap: support section-based vmemmap optimization Muchun Song
2026-08-19 9:51 ` [PATCH v4 09/17] mm/sparse: initialize memory sections earlier Muchun Song
2026-08-19 9:51 ` [PATCH v4 10/17] mm/hugetlb: switch HugeTLB to section-based vmemmap optimization Muchun Song
2026-08-19 9:51 ` [PATCH v4 11/17] mm/sparse-vmemmap: remove SPARSEMEM_VMEMMAP_PREINIT support Muchun Song
2026-08-19 9:51 ` [PATCH v4 12/17] mm/sparse: inline usemap allocation into sparse_init_nid() Muchun Song
2026-08-19 9:51 ` [PATCH v4 13/17] mm/sparse: remove section_map_size() Muchun Song
2026-08-19 9:51 ` [PATCH v4 14/17] mm/hugetlb: remove HUGE_BOOTMEM_HVO Muchun Song
2026-08-19 9:51 ` [PATCH v4 15/17] mm/hugetlb: remove HUGE_BOOTMEM_CMA Muchun Song
2026-08-19 9:51 ` [PATCH v4 16/17] mm/hugetlb: localize struct huge_bootmem_page Muchun Song
2026-08-19 9:51 ` [PATCH v4 17/17] mm/hugetlb: localize HUGE_BOOTMEM_ZONES_VALID Muchun Song
2026-08-19 11:30 ` Muchun Song [this message]
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=BDDE93CF-876C-4A65-A4F7-C717CDCE61F4@linux.dev \
--to=muchun.song@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=david.laight.linux@gmail.com \
--cc=david@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=rppt@kernel.org \
--cc=songmuchun@bytedance.com \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox