From: Muchun Song <songmuchun@bytedance.com>
To: David Hildenbrand <david@kernel.org>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Mike Rapoport <rppt@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Lance Yang <lance.yang@linux.dev>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <chleroy@kernel.org>,
Ritesh Harjani <ritesh.list@gmail.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Oscar Salvador <osalvador@suse.de>, Qi Zheng <qi.zheng@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org, x86@kernel.org,
loongarch@lists.linux.dev, linux-s390@vger.kernel.org,
Muchun Song <songmuchun@bytedance.com>
Subject: [PATCH v2 0/5] mm: Simplify device DAX vmemmap optimization plumbing
Date: Thu, 5 Nov 2026 14:12:12 +0800 [thread overview]
Message-ID: <20261105061217.13302-1-songmuchun@bytedance.com> (raw)
Hi,
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: simplifying the device DAX vmemmap
optimization plumbing.
After device DAX was converted to section-based vmemmap optimization,
whether a mapping can be optimized is carried in mem_section, and the
architecture-specific population path can handle any remaining fallback.
The code still retains the DAX-specific vmemmap_can_optimize() helper, a
PowerPC override, and @pgmap arguments threaded through lower-level
vmemmap population and memory-removal interfaces. These duplicate the
section-order policy and keep otherwise generic paths coupled to
dev_pagemap.
This series removes that obsolete plumbing by consolidating the
optimization policy around memory-section metadata and simplifying the
generic and architecture-specific population paths. This also eliminates
dependencies that are no longer needed once the optimization state is
carried by the memory section.
This leaves the section compound order as the single source of truth for
vmemmap optimization and decouples the generic sparse-vmemmap and
memory-hotplug paths from device DAX.
This is another smaller step toward the broader HVO generalization.
[1] https://lore.kernel.org/20260513130542.35604-1-songmuchun@bytedance.com/
v2:
- Rebase onto mm-new at dba8aba0a9a0
- Add section_vmemmap_optimization_disable() and use it for PowerPC,
LoongArch, and altmap fallbacks.
- Add a LoongArch patch that keeps device DAX vmemmap optimization
disabled while leaving HugeTLB HVO unchanged.
- Ignore section compound orders that cannot be optimized.
- Add direct vmemmap-optimization.h includes for architecture users.
v1: https://lore.kernel.org/20261030140720.1256062-1-songmuchun@bytedance.com/
Muchun Song (5):
powerpc/mm: make vmemmap_populate_compound_pages() static
powerpc/mm: drop powerpc vmemmap_can_optimize()
loongarch/mm: disable device DAX vmemmap optimization
mm/sparse-vmemmap: drop vmemmap_can_optimize()
mm/sparse-vmemmap: drop @pgmap from vmemmap population APIs
arch/arm64/mm/mmu.c | 5 +-
arch/loongarch/mm/init.c | 7 +--
arch/powerpc/include/asm/book3s/64/radix.h | 12 -----
arch/powerpc/mm/book3s64/radix_pgtable.c | 23 +++------
arch/powerpc/mm/init_64.c | 2 +
arch/powerpc/mm/mem.c | 5 +-
arch/riscv/mm/init.c | 5 +-
arch/s390/mm/init.c | 5 +-
arch/x86/mm/init_64.c | 5 +-
include/linux/memory_hotplug.h | 8 ++--
include/linux/mm.h | 40 +---------------
include/linux/vmemmap-optimization.h | 56 +++++++++++++++++-----
mm/memory_hotplug.c | 16 +++----
mm/memremap.c | 4 +-
mm/sparse-vmemmap.c | 29 ++++++-----
mm/sparse.c | 6 +--
mm/sparse.h | 5 --
17 files changed, 97 insertions(+), 136 deletions(-)
base-commit: dba8aba0a9a00ff781c03d82ae534fc6f8c2e263
--
2.54.0
next reply other threads:[~2026-11-05 6:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 6:12 Muchun Song [this message]
2026-11-05 6:12 ` [PATCH v2 1/5] powerpc/mm: make vmemmap_populate_compound_pages() static Muchun Song
2026-11-06 4:38 ` Lance Yang
2026-11-05 6:12 ` [PATCH v2 2/5] powerpc/mm: drop powerpc vmemmap_can_optimize() Muchun Song
2026-11-05 12:13 ` kernel test robot
2026-11-05 6:12 ` [PATCH v2 3/5] loongarch/mm: disable device DAX vmemmap optimization Muchun Song
2026-11-05 6:12 ` [PATCH v2 4/5] mm/sparse-vmemmap: drop vmemmap_can_optimize() Muchun Song
2026-11-05 6:12 ` [PATCH v2 5/5] mm/sparse-vmemmap: drop @pgmap from vmemmap population APIs 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=20261105061217.13302-1-songmuchun@bytedance.com \
--to=songmuchun@bytedance.com \
--cc=akpm@linux-foundation.org \
--cc=chenhuacai@kernel.org \
--cc=chleroy@kernel.org \
--cc=david@kernel.org \
--cc=kernel@xen0n.name \
--cc=lance.yang@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=muchun.song@linux.dev \
--cc=npiggin@gmail.com \
--cc=osalvador@suse.de \
--cc=qi.zheng@linux.dev \
--cc=ritesh.list@gmail.com \
--cc=rppt@kernel.org \
--cc=sshegde@linux.ibm.com \
--cc=x86@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
all inboxes | Powered by JetHome®