[PATCH v2 00/11] mm: Switch device DAX to section-based vmemmap optimization

Muchun Song posted 11 patches 2 weeks, 3 days ago
There is a newer version of this series
Documentation/arch/powerpc/vmemmap_dedup.rst  |  90 ++-------
Documentation/mm/vmemmap_dedup.rst            |  32 +--
MAINTAINERS                                   |   1 +
arch/powerpc/mm/book3s64/radix_pgtable.c      | 124 +-----------
arch/x86/entry/vdso/vdso32/fake_32bit_build.h |   2 +-
drivers/dax/Kconfig                           |   2 +
fs/Kconfig                                    |   1 +
include/linux/mm.h                            |   6 +-
include/linux/mmzone.h                        |  23 ++-
include/linux/page-flags.h                    |   5 +-
include/linux/vmemmap-optimization.h          |  91 +++++++++
mm/Kconfig                                    |   4 +
mm/hugetlb.c                                  |   2 +-
mm/hugetlb_vmemmap.c                          |  30 +--
mm/internal.h                                 |   9 -
mm/memory_hotplug.c                           |   6 +-
mm/mm_init.c                                  |  17 +-
mm/sparse-vmemmap.c                           | 184 ++++++++----------
mm/sparse.c                                   |   3 +-
mm/sparse.h                                   |  78 +-------
20 files changed, 250 insertions(+), 460 deletions(-)
create mode 100644 include/linux/vmemmap-optimization.h
[PATCH v2 00/11] mm: Switch device DAX to section-based vmemmap optimization
Posted by Muchun Song 2 weeks, 3 days ago
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: switching device DAX to the section-based
sparse-vmemmap optimization infrastructure introduced for HugeTLB.

After the HugeTLB conversion, optimized vmemmap state is described by
the memory section and the sparse-vmemmap population path can allocate or
reuse shared tail vmemmap pages based on that metadata. Device DAX still
uses the older DAX-specific population model, including a separate tail
vmemmap page reservation and architecture-specific logic to locate or
populate reusable tail pages.

This series makes device DAX use the same section-based model. Device DAX
sets the section order from pgmap->vmemmap_shift before vmemmap
population, uses the common per-zone shared tail vmemmap page, and drops
the extra reserved tail page. The powerpc radix path is updated to use
the same shared tail-page helper, so the generic and powerpc DAX paths
follow the same reservation model.

The first patches prepare the shared infrastructure by introducing a
generic CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION symbol, factoring out
shared tail-page allocation, and keeping the special shared-tail struct
page initialization local to sparse-vmemmap.

The middle patches move device DAX onto that infrastructure by recording
the device DAX compound page order in the memory section, using that
section metadata to back generic device DAX mappings with the common
per-zone shared tail page, exposing the shared helpers so the powerpc
radix path can use the same model, and dropping the extra DAX-only tail
page reservation and the now-unused section accounting arguments.

The final patch updates the documentation for the new DAX layout.

This is intended to be the third smaller step toward the broader HVO
generalization. The wider HVO consolidation between HugeTLB and device
DAX is left for follow-up series.

v2:
- Add a missing SPARSEMEM_VMEMMAP dependency (suggested by Qi Zheng,
  reported by Sashiko)
- Add an explicit ZONE_DEVICE dependency for DEV_DAX
- Add missing dependencies to the new public header
- Explain why optimized and ordinary layouts cannot share a section
  (suggested by Qi Zheng)
- Explain why sharing tail vmemmap pages is safe for DEV-DAX (suggested
  by Qi Zheng)
- Clarify the removal of duplicated 4K PUD calculations from the docs
  (reported by Sashiko)
- Collect Acked-by tags from Qi Zheng

v1: https://lore.kernel.org/all/20260831075342.57563-1-songmuchun@bytedance.com/

[1] https://lore.kernel.org/all/20260513130542.35604-1-songmuchun@bytedance.com/

Muchun Song (11):
  mm/sparse-vmemmap: introduce CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION
  mm/sparse-vmemmap: factor out shared vmemmap tail page allocation
  mm/sparse-vmemmap: open-code init_compound_tail()
  mm/sparse-vmemmap: prepare DAX vmemmap population for section orders
  mm/sparse-vmemmap: set section order for device DAX
  mm/sparse-vmemmap: switch device DAX to shared tail vmemmap pages
  mm/sparse-vmemmap: move HVO helpers to a public header
  powerpc/mm: switch device DAX to shared tail vmemmap pages
  mm/sparse-vmemmap: drop the extra tail page from device DAX
    reservation
  mm/sparse-vmemmap: drop unused section_nr_vmemmap_pages() arguments
  Documentation/mm: update DAX vmemmap deduplication docs

 Documentation/arch/powerpc/vmemmap_dedup.rst  |  90 ++-------
 Documentation/mm/vmemmap_dedup.rst            |  32 +--
 MAINTAINERS                                   |   1 +
 arch/powerpc/mm/book3s64/radix_pgtable.c      | 124 +-----------
 arch/x86/entry/vdso/vdso32/fake_32bit_build.h |   2 +-
 drivers/dax/Kconfig                           |   2 +
 fs/Kconfig                                    |   1 +
 include/linux/mm.h                            |   6 +-
 include/linux/mmzone.h                        |  23 ++-
 include/linux/page-flags.h                    |   5 +-
 include/linux/vmemmap-optimization.h          |  91 +++++++++
 mm/Kconfig                                    |   4 +
 mm/hugetlb.c                                  |   2 +-
 mm/hugetlb_vmemmap.c                          |  30 +--
 mm/internal.h                                 |   9 -
 mm/memory_hotplug.c                           |   6 +-
 mm/mm_init.c                                  |  17 +-
 mm/sparse-vmemmap.c                           | 184 ++++++++----------
 mm/sparse.c                                   |   3 +-
 mm/sparse.h                                   |  78 +-------
 20 files changed, 250 insertions(+), 460 deletions(-)
 create mode 100644 include/linux/vmemmap-optimization.h


base-commit: 9d3243fc689fef444f87e0a703b4c99653137e1b
-- 
2.54.0
Re: [PATCH v2 00/11] mm: Switch device DAX to section-based vmemmap optimization
Posted by Andrew Morton 2 weeks, 2 days ago
On Tue,  8 Sep 2026 11:03:24 +0800 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: switching device DAX to the section-based
> sparse-vmemmap optimization infrastructure introduced for HugeTLB.
> 
> ...
> 
> This is intended to be the third smaller step toward the broader HVO
> generalization. The wider HVO consolidation between HugeTLB and device
> DAX is left for follow-up series.

Thanks both, I'll add it to mm.git's mm-new branch.
Re: [PATCH v2 00/11] mm: Switch device DAX to section-based vmemmap optimization
Posted by Muchun Song 2 weeks, 1 day ago

> On Sep 9, 2026, at 09:45, Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> On Tue,  8 Sep 2026 11:03:24 +0800 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: switching device DAX to the section-based
>> sparse-vmemmap optimization infrastructure introduced for HugeTLB.
>> 
>> ...
>> 
>> This is intended to be the third smaller step toward the broader HVO
>> generalization. The wider HVO consolidation between HugeTLB and device
>> DAX is left for follow-up series.
> 
> Thanks both, I'll add it to mm.git's mm-new branch.

Hi Andrew,

I've updated series [1] to v6 to address David's review comments from
yesterday. Since the current series depends on this v6 version, I suggest
dropping these two series from mm-new. Once the v6 version of the dependent
series is merged in, I will re-update the current series to v3 based on the
new mm-new branch, and also fix the compilation error under !CONFIG_NUMA [2]
in that version.

[1] https://lore.kernel.org/all/20260910063256.64386-1-songmuchun@bytedance.com/
[2] https://lore.kernel.org/all/202609100517.0DrzxrW4-lkp@intel.com/

Thanks,
Muchun