On 9/27/26 04:54, Muchun Song wrote: > HugeTLB vmemmap optimization now uses per-zone shared tail vmemmap pages. > Device DAX has not been switched to that mechanism yet. > > Switch device DAX to vmemmap_shared_tail_page() as well. This aligns DAX > with HugeTLB by using the common per-zone shared tail vmemmap page. > > The optimization is enabled only for DEV-DAX through pgmap->vmemmap_shift, > which supplies the compound page order recorded in section metadata before > vmemmap population. Unlike FS-DAX, DEV-DAX does not modify tail struct > pages, so sharing them is safe. > > Since the shared tail page can now back ZONE_DEVICE vmemmap mappings, > initialize its entries with PG_reserved for device zones. Also skip > poisoning vmemmap-optimizable sections while their struct pages may be > shared. > > Signed-off-by: Muchun Song <[email protected]> > Acked-by: Qi Zheng <[email protected]> > --- > v3: > - Move device_zone() after the definition of NODE_DATA() to fix > non-NUMA builds. > - Update the commit message to describe the compound page order stored > in section metadata > - Collect Acked-by from Qi Zheng > > v2: > - Explain why sharing tail vmemmap pages is safe for DEV-DAX > (suggested by Qi Zheng) > ---
[...] > - > static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn, > unsigned long start, > unsigned long end, int > node, > @@ -551,21 +536,18 @@ static int __meminit > vmemmap_populate_compound_pages(unsigned long start_pfn, > pte_t *pte; > int rc; > unsigned long flags = VMEMMAP_POPULATE_DAX; > + struct page *page; > + unsigned int order = pfn_to_section_compound_order(start_pfn); const and all the way to the top. I did wonder about the poisoning change ... because the memmap usually gets initialized once the memory section gets moved to a zone. SO now I'm a bit confused about the ordering of events :) -- Cheers, David
