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

On Sep 28, 2026, at 20:44, David Hildenbrand (Arm) [off-list ref] wrote:

On 9/24/26 09:52, Muchun Song wrote:

quoted

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: 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/all/20260513130542.35604-1-songmuchun@bytedance.com/ (local)

How does this series relate to

https://lore.kernel.org/r/20260927025441.741633-1-songmuchun@bytedance.com (local)

This series is based on the v4 version [1] of the series you pointed out. When
I was sending the current series, the v4 version of that series had already
been in mm-new for some time, so I sent the v2 version of the current series.

However, a couple of days ago the kernel test bot reported an issue, and this
issue cannot be easily fixed with a simple fixup. So I updated that series to
a v5 version.

Therefore, the current series needs to be rebased on top of the v5 version of
the series you pointed out, and then sent as a new v3 version before it can be
properly applied or reviewed.

If you're planning to review this series, I'd suggest waiting for my rebased
version.

[1] https://lore.kernel.org/all/20260916064341.1825793-1-songmuchun@bytedance.com/ (local)

Thanks,
Muchun

?

-- 
Cheers,

David