Re: [PATCH v5 06/12] mm/sparse-vmemmap: set compound page order for device DAX

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

On 9/27/26 04:54, Muchun Song wrote:
> Device DAX can use vmemmap optimization only when a full section is
> populated with a compound-page geometry. Record that geometry as the
> compound page order in section metadata before populating the section, so
> later vmemmap accounting and population decisions can use the section state
> directly.
> 
> Clear the compound page order when the section becomes empty again. Also
> reject partial additions to a section that already has optimized vmemmap
> mappings. compound_nr_pages() determines how many struct pages to
> initialize with a section as the smallest granularity. A section therefore
> cannot safely mix optimized and ordinary vmemmap layouts.
> 
> Partial additions continue to use ordinary vmemmap population, so they do
> not save vmemmap memory. Such additions are uncommon, and the lost saving
> is negligible.
> 
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> Acked-by: Qi Zheng <qi.zheng@linux.dev>
> ---
> v3:
> - Update the subject and commit message to use compound page order
>   terminology
> - Use EOPNOTSUPP instead of ENOTSUPP
> 
> v2:
> - Explain why optimized and ordinary layouts cannot share a section
>   (suggested by Qi Zheng)
> - Collect Acked-by from Qi Zheng
> ---

[...]>
>  static struct page * __meminit section_activate(int nid, unsigned long pfn,
> @@ -838,8 +840,13 @@ static struct page * __meminit section_activate(int nid, unsigned long pfn,
>  	struct mem_section *ms = __pfn_to_section(pfn);
>  	struct mem_section_usage *usage = NULL;
>  	struct page *memmap;
> +	unsigned int order;
>  	int rc;
>  
> +	order = vmemmap_can_optimize(altmap, pgmap) ? pgmap->vmemmap_shift : 0;
> +	if (nr_pages < PAGES_PER_SECTION && section_compound_order(ms))
> +		return ERR_PTR(-EOPNOTSUPP);

Hm. Why should we support optimizing the vmemmap in case we fall into the same
memory section as boot memory?

In that case, there already is a memmap allocated during boot for the entire
section. IOW, we really shouldn't mess with the vmemmap in case we have an early
section.

But maybe I am missing something and this is already disallowed?

-- 
Cheers,

David