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

[David Hildenbrand (Arm)]

On 9/29/26 10:22, Muchun Song wrote:
> 
> 
>> On Sep 29, 2026, at 15:30, David Hildenbrand (Arm) <david@xxxxxxxxxx> 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@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?
> 
> 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.

Perfect, thanks

Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>

-- 
Cheers,

David