> On Sep 29, 2026, at 15:36, David Hildenbrand (Arm) <[email protected]> wrote:
>
> On 9/27/26 04:54, Muchun Song wrote:
>> HugeTLB vmemmap optimization now uses per-zone shared tail vmemmap pages.
>> Device DAX has not been switched to that mechanism yet.
>>
>> Switch device DAX to vmemmap_shared_tail_page() as well. This aligns DAX
>> with HugeTLB by using the common per-zone shared tail vmemmap page.
>>
>> The optimization is enabled only for DEV-DAX through pgmap->vmemmap_shift,
>> which supplies the compound page order recorded in section metadata before
>> vmemmap population. Unlike FS-DAX, DEV-DAX does not modify tail struct
>> pages, so sharing them is safe.
>>
>> Since the shared tail page can now back ZONE_DEVICE vmemmap mappings,
>> initialize its entries with PG_reserved for device zones. Also skip
>> poisoning vmemmap-optimizable sections while their struct pages may be
>> shared.
>>
>> Signed-off-by: Muchun Song <[email protected]>
>> Acked-by: Qi Zheng <[email protected]>
>> ---
>> v3:
>> - Move device_zone() after the definition of NODE_DATA() to fix
>> non-NUMA builds.
>> - Update the commit message to describe the compound page order stored
>> in section metadata
>> - Collect Acked-by from Qi Zheng
>>
>> v2:
>> - Explain why sharing tail vmemmap pages is safe for DEV-DAX
>> (suggested by Qi Zheng)
>> ---
>
> [...]
>
>> -
>> static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn,
>> unsigned long start,
>> unsigned long end, int node,
>> @@ -551,21 +536,18 @@ static int __meminit
>> vmemmap_populate_compound_pages(unsigned long start_pfn,
>> pte_t *pte;
>> int rc;
>> unsigned long flags = VMEMMAP_POPULATE_DAX;
>> + struct page *page;
>> + unsigned int order = pfn_to_section_compound_order(start_pfn);
>
> const and all the way to the top.
OK.
>
>
> I did wonder about the poisoning change ... because the memmap usually gets
> initialized once the memory section gets moved to a zone.
>
> SO now I'm a bit confused about the ordering of events :)
Yes, the normal memmap entries are initialized later when the range is
moved into the zone. The shared tail entries are the exception, though.
The ordering for device DAX is:
1. sparse_add_section() sets the section compound order and populates
the vmemmap.
2. During vmemmap population, optimizable tail entries are mapped to
the per-zone shared tail page, which is initialized by
vmemmap_shared_tail_page().
3. page_init_poison() is reached after that population.
4. Later, move_pfn_range_to_zone() calls memmap_init_range(), but the
latter deliberately skips vmemmap_optimizable_pfn() because those
entries have already been initialized.
Therefore, an unconditional poison here would overwrite the initialized
shared tail page, and the later zone initialization would not restore it.
The non-shared entries are still initialized later as usual.
I agree that this ordering is not obvious. I will update the comment to
make it clearer, for example:
/*
* Poison uninitialized struct pages to catch invalid flag combinations.
*
* Tail struct pages in a vmemmap-optimized section are initialized and
* shared during vmemmap population, so they must not be overwritten here.
*/
Thanks,
Muchun
>
> --
> Cheers,
>
> David
