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

- From: Muchun Song \<muchun.song@linux.dev\>
- Date: 2026-05-14 02:38:13 
- List: linuxppc-dev
- Page: https://ratatoskr.run/linuxppc-dev/2026/05/9005626
- Thread: https://ratatoskr.run/linux-mm/2026/05/9003574/t.md

```text


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

Thanks.

> this series in fixes-that-can-go-straight-away and the feature itself would make more
> sense and help ease the review.

Yes.

> Head tends to spin a bit when the patchset grows beyond certain number of patches :-D.
> 
> Would that be possible Munchun?

I'd prefer to group the first 19 patches into a single series (titled
"Refactor bootmem gigantic hugepage allocation"). Therefore, waiting
for your review. :)

Once patches 13-19 pass review, I will send them out as a standalone
series.

Muchun,
Thanks.

> 
> 
> 
> -- 
> Oscar Salvador
> SUSE Labs



```
