Re: [PATCH v5 07/12] mm/sparse-vmemmap: switch device DAX to shared tail vmemmap pages

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

> On Sep 29, 2026, at 15:36, David Hildenbrand (Arm) <david@kernel.org> 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 <songmuchun@bytedance.com>
>> Acked-by: Qi Zheng <qi.zheng@linux.dev>
>> ---
>> 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