Re: [PATCH v3 0/6] mm: Unify device DAX and HugeTLB vmemmap population paths

On Sep 30, 2026, at 05:32, Andrew Morton [off-list ref] wrote:

On Tue, 29 Sep 2026 13:32:25 +0800 Muchun Song [off-list ref] wrote:

quoted

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.

afaict the whole series is "no functional changes intended".  Apart
from [6/6]'s new WARN_ON.

Yes.

And [3/6] is the one which could cause unintended fuctional changes!

Understood. However, the resulting vmemmap layout is intended to remain
unchanged.

Thanks.  I'll queue it.  Reluctantly.  We're up to 688 MM patches this
cycle and it's time to stop.

Thanks for taking it despite the load.

Muchun,
Thanks.