From: Muchun Song <songmuchun@bytedance.com>
To: Madhavan Srinivasan <maddy@linux.ibm.com>,
Mike Rapoport <rppt@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>
Cc: 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>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R . Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Qi Zheng <qi.zheng@linux.dev>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Muchun Song <songmuchun@bytedance.com>,
muchun.song@linux.dev
Subject: [PATCH v3 0/6] mm: Unify device DAX and HugeTLB vmemmap population paths
Date: Tue, 29 Sep 2026 13:32:25 +0800 [thread overview]
Message-ID: <20260929053231.66085-1-songmuchun@bytedance.com> (raw)
This v3 is based on mm-new commit 2ddb90ee544a, which contains v5 of
"mm: Switch device DAX to section-based vmemmap optimization" [1].
This series is split out from the earlier, larger series "mm: Generalize
HVO for HugeTLB and device DAX" [2]. While the parent series generalizes
vmemmap optimization across HugeTLB and device DAX, this subset addresses
a single, self-contained step: unifying their vmemmap population paths.
After the preceding Device DAX conversion, both HugeTLB and Device DAX
describe optimized vmemmap mappings through memory-section metadata and
use per-zone shared tail vmemmap pages. The generic code, however, still
carries a Device DAX-specific population flag and compound-page population
path, along with arguments and helpers needed only by that path.
This series first removes VMEMMAP_POPULATE_DAX and moves selection and
reference handling for the shared tail page into the common vmemmap
population path. It then removes the generic Device DAX-specific
compound-page population path and routes section vmemmap population
through vmemmap_populate(). The powerpc radix path continues to use its
architecture-specific compound-page population implementation for
optimizable sections.
The remaining patches remove the unused ptpfn argument, open-code
vmemmap_populate_address() now that no caller needs its returned PTE, and
add a warning for inconsistent zone initialization of shared tail vmemmap
pages.
This is the fourth smaller step toward the broader HVO generalization.
After this series, HugeTLB and Device DAX use the same population model
instead of parallel generic paths, while powerpc keeps its
architecture-specific implementation.
[1] https://lore.kernel.org/20260927025441.741633-1-songmuchun@bytedance.com/
[2] https://lore.kernel.org/20260513130542.35604-1-songmuchun@bytedance.com/
v3:
- Rebase onto mm-new commit 2ddb90ee544a, which contains v5 of the Device
DAX section-based vmemmap series.
- Document the exact dependency order as suggested by David Hildenbrand
and Ritesh Harjani.
- Use the public order-based optimization predicate in the powerpc path.
- Collect Acked-by tags from Qi Zheng.
v2: https://lore.kernel.org/20260924075259.2013039-1-songmuchun@bytedance.com/
- Expand the comments around the slab initialization boundary as suggested
by Qi Zheng.
- Collect Acked-by tags from Qi Zheng.
- Defer the patch making vmemmap_populate_compound_pages() static to a
follow-up series that cleans up the powerpc vmemmap population code.
- Add a new patch to warn about mismatched zone IDs between a page and its
shared tail vmemmap page.
v1: https://lore.kernel.org/20260913083734.86802-1-songmuchun@bytedance.com/
Muchun Song (6):
mm/sparse-vmemmap: drop VMEMMAP_POPULATE_DAX
mm/sparse-vmemmap: support device DAX in common vmemmap path
mm/sparse-vmemmap: drop Device DAX-specific population path
mm/sparse-vmemmap: remove the unused ptpfn argument
mm/sparse-vmemmap: open-code vmemmap_populate_address()
mm/mm_init: add zone mismatch warning during page init
arch/powerpc/mm/book3s64/radix_pgtable.c | 3 +
mm/mm_init.c | 5 +-
mm/sparse-vmemmap.c | 208 ++++++-----------------
3 files changed, 63 insertions(+), 153 deletions(-)
base-commit: 2ddb90ee544ae97215afc4698dc223293997cc43
--
2.54.0
next reply other threads:[~2026-09-29 5:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 5:32 Muchun Song [this message]
2026-09-29 5:32 ` [PATCH v3 1/6] mm/sparse-vmemmap: drop VMEMMAP_POPULATE_DAX Muchun Song
2026-09-30 4:24 ` Lance Yang
2026-09-29 5:32 ` [PATCH v3 2/6] mm/sparse-vmemmap: support device DAX in common vmemmap path Muchun Song
2026-09-30 8:53 ` Lance Yang
2026-09-30 10:09 ` Muchun Song
2026-09-30 10:02 ` Lance Yang
2026-09-29 5:32 ` [PATCH v3 3/6] mm/sparse-vmemmap: drop Device DAX-specific population path Muchun Song
2026-09-29 5:32 ` [PATCH v3 4/6] mm/sparse-vmemmap: remove the unused ptpfn argument Muchun Song
2026-09-29 5:32 ` [PATCH v3 5/6] mm/sparse-vmemmap: open-code vmemmap_populate_address() Muchun Song
2026-09-29 5:32 ` [PATCH v3 6/6] mm/mm_init: add zone mismatch warning during page init Muchun Song
2026-09-29 21:32 ` [PATCH v3 0/6] mm: Unify device DAX and HugeTLB vmemmap population paths Andrew Morton
2026-09-30 1:26 ` 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=20260929053231.66085-1-songmuchun@bytedance.com \
--to=songmuchun@bytedance.com \
--cc=akpm@linux-foundation.org \
--cc=chleroy@kernel.org \
--cc=david@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=ljs@kernel.org \
--cc=maddy@linux.ibm.com \
--cc=mhocko@suse.com \
--cc=mpe@ellerman.id.au \
--cc=muchun.song@linux.dev \
--cc=npiggin@gmail.com \
--cc=qi.zheng@linux.dev \
--cc=ritesh.list@gmail.com \
--cc=rppt@kernel.org \
--cc=sshegde@linux.ibm.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
all inboxes | Powered by JetHome®