On 9/24/26 09:52, Muchun Song wrote: > 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/[email protected]/
How does this series relate to https://lore.kernel.org/r/[email protected] ? -- Cheers, David
