Re: [PATCH 1/6] mm/sparse-vmemmap: drop VMEMMAP_POPULATE_DAX

On Sep 21, 2026, at 11:43, Qi Zheng [off-list ref] wrote:
On 9/19/26 10:07 PM, Muchun Song wrote:

quoted

quoted

On Sep 19, 2026, at 22:01, Qi Zheng [off-list ref] wrote:
On 9/13/26 4:37 PM, Muchun Song wrote:

quoted

VMEMMAP_POPULATE_DAX currently distinguishes DAX vmemmap population in two
places: it keeps allocations on the normal path and takes a reference when
a backing page is supplied for reuse.
After Device DAX switched to the common per-zone shared tail page, both
conditions can be determined locally. DAX supplies ptpfn for every shared
tail mapping and requests an allocation only for compound head mappings,
whose PFNs are not optimizable. Therefore, vmemmap_optimizable_pfn() alone
selects the correct allocation path.
When ptpfn is supplied, the caller is reusing an existing backing page.
Once the slab allocator is available, take a reference for each reused

Does the availability of slab mean the buddy allocator is already being
used? Could there be a window where the buddy allocator is functional
but slab hasn't become available yet?

Yes, because the slab allocator is based on buddy allocator. But I want to know
what's your concern here?

The goal here is to check if the buddy allocator is ready, but the code
actually checks for slab.

I'm concerned there could be a gap between these two:

buddy is ready <-- gap --> slab is ready

There is no vmemmap population during the gap. We don't need to concern the gap.

Thanks.

Thanks,
Qi