Re: [PATCH v2 00/69] mm: Generalize HVO for HugeTLB and device DAX

On Wed, May 13, 2026 at 10:46:40AM -0700, Andrew Morton wrote:

On Wed, 13 May 2026 21:04:28 +0800 Muchun Song [off-list ref] wrote:

quoted

In this series, HVO is redefined as Hugepage Vmemmap Optimization: a
general vmemmap optimization model for large hugepage-backed mappings,
rather than a HugeTLB-only implementation detail.

The existing code grew around the original HugeTLB-specific HVO path,
while device DAX developed similar but separate vmemmap optimization
handling. As a result, the current implementation carries duplicated
logic, boot-time special cases, and subsystem-specific interfaces around
what is fundamentally the same sparse-vmemmap optimization.

This series generalizes that optimization into a common framework used
by both HugeTLB and device DAX.

The first few patches include some minor bug fixes found during AI-aided
review of the current code. These fixes are not the main goal of the
series, but the later refactoring and unification work depends on them,
so they are included here as preparatory changes.

The series then reworks the relevant early boot and sparse
initialization paths, introduces a generic section-based sparse-vmemmap
optimization infrastructure, switches HugeTLB and device DAX over to the
shared implementation, and removes the old special-case code.

...

 46 files changed, 743 insertions(+), 1812 deletions(-)

Gulp.

I think the first 15ish patches (little fixes and cleanups and
refactorings) are ready to go in immediately?

I plan to have a (partial ) look at this tomorrow/Friday, but splitting
this series in fixes-that-can-go-straight-away and the feature itself would make more
sense and help ease the review.
Head tends to spin a bit when the patchset grows beyond certain number of patches :-D.

Would that be possible Munchun?

 

-- 
Oscar Salvador
SUSE Labs