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

[Muchun Song <muchun.song@linux.dev>]

> On Sep 29, 2026, at 15:30, David Hildenbrand (Arm) <david@kernel.org> wrote:
> 
> 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?

Yes, this is already handled.

For a partial addition to a normal early section, after updating the
subsection map we return the existing boot-time memmap here:

	if (nr_pages < PAGES_PER_SECTION && early_section(ms))
		return pfn_to_page(pfn);

Therefore, neither section_set_compound_order_range() nor
populate_section_memmap() is called. The fully populated boot memmap is
simply reused, and no vmemmap optimization is attempted.

The check above handles the other case: if the section already has an
optimized vmemmap layout, as indicated by section_compound_order(ms),
a partial addition is rejected because we cannot mix optimized and
ordinary vmemmap layouts within one section. This also covers an early
section whose vmemmap was already optimized during boot.

Thanks,
Muchun


> 
> -- 
> Cheers,
> 
> David