Re: [PATCH v3 00/12] mm: Decouple folio-based vmemmap optimization from HugeTLB

[Muchun Song]

> On Nov 4, 2026, at 14:46, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> On Wed,  4 Nov 2026 10:34:58 +0800 Muchun Song <songmuchun@xxxxxxxxxxxxx> wrote:
> 
>> Hi,
>> 
>> Section-based vmemmap optimization is implemented in sparse-vmemmap.c,
>> while folio-based optimization currently lives in hugetlb_vmemmap.c.
>> The latter is tightly coupled to HugeTLB-specific state even though the
>> underlying page-table remapping operates on one folio at a time.
>> 
>> To make these interfaces easier to maintain, the folio-based remapping
>> mechanics first need a boundary that is independent of HugeTLB-specific
>> state and raw address ranges. This will allow the mechanics to be moved
>> into a common vmemmap optimization layer alongside the section-based
>> interface.
>> 
>> This series establishes that boundary through three folio-oriented
>> operations, each with a distinct role:
>> 
>>  - vmemmap_optimize_folio() optimizes the vmemmap backing of a folio;
>>  - vmemmap_restore_folio() restores the vmemmap backing of a folio; and
>>  - vmemmap_pteify_folio() converts the vmemmap backing of a folio to
>>    PTE mappings.
>> 
>> Together, these operations encapsulate the address-range calculation and
>> remapping mechanics for a folio. HugeTLB wrappers retain policy decisions
>> such as eligibility, optimized state, batching and TLB flush handling.
>> 
>> Patches 1-8 generalize the underlying vmemmap remapping infrastructure by
>> removing HugeTLB-specific assumptions and simplifying remap control and
>> resource handling. Patches 9-12 then establish folio-oriented operations
>> for optimization, restoration and PTE conversion.
>> 
>> The implementation remains in hugetlb_vmemmap.c for now. A follow-up can
>> move the folio-based operations into the common vmemmap optimization layer
>> once the interface boundary is in place.
>> 
> 
> Thanks.  I fed this into my evolving LLM-controlled testing setup and it
> said
> 
> : I tested all twelve patches together in an x86-64 Debian VM under
> : QEMU/KVM, with 4 KiB base pages and KASAN enabled.
> :
> : I grew the pool by 64 two-MiB huge pages and drained it again. With
> : vmemmap optimization enabled, the kernel released 448 vmemmap pages
> : on growth and restored all 448 on shrink, in each of three cycles.
> : With optimization disabled, the vmemmap count stayed constant. I also
> : faulted in a single surplus huge page. It released seven vmemmap pages
> : and restored all seven when I unmapped it.
> :
> : I tested both boot-reserved and runtime-allocated 1 GiB huge pages.
> : For the runtime case, I grew the pool from zero to one, drained it,
> : and allocated again. I mapped the page and wrote and verified a byte
> : in every 4 KiB base page. After unmapping it, I demoted it to 512
> : two-MiB huge pages and drained the resulting pool.
> :
> : All twelve programs in the HugeTLB selftest group passed, including
> : the cgroup reservation, fault-charge and reparenting tests. Both
> : soft-offline cases passed, as did all twelve poisoned-page read test
> : cases. I saw no HugeTLB warnings or KASAN reports.
> :
> : On a diagnostic build, I failed the head-page allocation and, in a
> : separate run, interrupted optimization after three PTEs had changed.
> : The trace showed rollback restoring the two tail entries to distinct
> : backing pages. The folio remained usable in both runs. I also failed
> : restoration after three of seven replacement pages had been allocated.
> : All three were freed, the retry succeeded, and the metadata count
> : returned to its starting value.
> :
> : I configured QEMU with two virtual NUMA nodes, each with two vCPUs
> : and 4 GiB of RAM. On each node, I forced the batched pre-split to
> : fail. The trace showed the remap splitting the same PMD and completing
> : a range flush before replacing its first PTE. Folios on each node
> : shared a tail backing page distinct from the other node's. I drained
> : each node's pool in turn and verified data in a live folio on the other.
> :
> : Finally, on the kernel without diagnostic hooks, I grew and drained
> : both pools during active page-cache reclaim. Over 40 cycles all 640
> : folios optimized and restored, and the OOM-kill count stayed flat.

Really a thorough set of tests.

> :
> : Tested-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>

Thanks for testing.

Muchun