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

[Muchun Song]

> On Sep 19, 2026, at 22:01, Qi Zheng <qi.zheng@xxxxxxxxx> wrote:
> On 9/13/26 4:37 PM, Muchun Song wrote:
>> 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?