Re: [PATCH v5 07/12] mm/sparse-vmemmap: switch device DAX to shared tail vmemmap pages

["David Hildenbrand (Arm)" <david@kernel.org>]

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 <songmuchun@bytedance.com>
> Acked-by: Qi Zheng <qi.zheng@linux.dev>
> ---
> 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