Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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
> 



      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