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

From: David Hildenbrand (Arm)

Date: Tue Sep 29 2026 - 03:33:16 EST


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@xxxxxxxxxxxxx>
> Acked-by: Qi Zheng <qi.zheng@xxxxxxxxx>
> ---
> 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