Re: [PATCH v5 05/12] mm/sparse-vmemmap: prepare DAX vmemmap population for compound page orders

[David Hildenbrand (Arm)]

On 9/27/26 04:54, Muchun Song wrote:
> Device DAX still uses vmemmap_populate_compound_pages() to populate its
> compound-page vmemmap mappings. That helper allocates the head and first
> tail vmemmap pages explicitly, then reuses the first tail page for the
> remaining tail page mappings.
> 
> Device DAX is being moved to the section-based vmemmap optimization
> infrastructure, but it cannot switch to the generic section-based
> population path yet. Once a later patch records the DAX compound page
> order in section metadata, DAX head and first-tail PFNs can look
> optimizable to the generic helpers as well.
> 
> Add a DAX-specific population flag for this transition. It keeps DAX

Well, you're not adding flag, your reusing an existing one and renaming it?

And then you're specifying it on more paths.

[...]

>  mm/sparse-vmemmap.c | 27 +++++++++++++++------------
>  1 file changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
> index e4dae98ba7f8..2457ea2c6dca 100644
> --- a/mm/sparse-vmemmap.c
> +++ b/mm/sparse-vmemmap.c
> @@ -35,8 +35,8 @@
>  /*
>   * Flags for vmemmap_populate_range and friends.
>   */
> -/* Get a ref on the head page struct page, for ZONE_DEVICE compound pages */
> -#define VMEMMAP_POPULATE_PAGEREF	0x0001
> +/* Vmemmap population for ZONE_DEVICE compound pages */
> +#define VMEMMAP_POPULATE_DAX		0x0001

Cleaner.

>  
>  #include "internal.h"
>  #include "mm_init.h"
> @@ -243,13 +243,17 @@ static inline struct page *vmemmap_shared_tail_page(unsigned int order,
>  #endif
>  
>  static __meminit void *vmemmap_alloc_pte(unsigned long pfn, int node,
> -					 struct vmem_altmap *altmap)
> +		struct vmem_altmap *altmap, unsigned long flags)
>  {
>  	struct zone *zone;
>  	struct page *page;
>  	const unsigned int order = pfn_to_section_compound_order(pfn);
>  
> -	if (!vmemmap_optimizable_pfn(pfn))
> +	/*
> +	 * Device DAX still relies on vmemmap_populate_compound_pages() for
> +	 * head/first-tail allocation and tail-page reuse.
> +	 */
> +	if (!vmemmap_optimizable_pfn(pfn) || flags & VMEMMAP_POPULATE_DAX)
>  		return vmemmap_alloc_block_buf(PAGE_SIZE, node, altmap);
>  
>  	zone = pfn_to_zone(pfn, node);
> @@ -271,7 +275,7 @@ static pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, in
>  		pte_t entry;
>  
>  		if (ptpfn == (unsigned long)-1) {
> -			void *p = vmemmap_alloc_pte(pfn, node, altmap);
> +			void *p = vmemmap_alloc_pte(pfn, node, altmap, flags);
>  
>  			if (!p)
>  				return NULL;
> @@ -286,7 +290,7 @@ static pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, in
>  			 * and through vmemmap_populate_compound_pages() when
>  			 * slab is available.
>  			 */
> -			if (flags & VMEMMAP_POPULATE_PAGEREF)
> +			if (flags & VMEMMAP_POPULATE_DAX)
>  				get_page(pfn_to_page(ptpfn));
>  		}
>  		entry = pfn_pte(ptpfn, PAGE_KERNEL);
> @@ -546,6 +550,7 @@ static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn,
>  	unsigned long size, addr;
>  	pte_t *pte;
>  	int rc;
> +	unsigned long flags = VMEMMAP_POPULATE_DAX;

const and at the top?

-- 
Cheers,

David