On Wed, May 13, 2026 at 10:46:40AM -0700, Andrew Morton wrote: > On Wed, 13 May 2026 21:04:28 +0800 Muchun Song <[email protected]> > wrote: > > > 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
