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

On Sep 29, 2026, at 15:36, David Hildenbrand (Arm) [off-list ref] wrote:

On 9/27/26 04:54, Muchun Song wrote:

quoted

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 <redacted>
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)
---

[...]

quoted

-
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