Re: [PATCH 3/4] mm: add shared read-only vmemmap support for FS-DAX

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

> On Sep 21, 2026, at 14:42, Gupta, Pankaj <pankaj.gupta@amd.com> wrote:
> 
>> 
>> FS-DAX registers persistent-memory ranges as ZONE_DEVICE memory, and the
>> kernel normally allocates and initializes vmemmap storage for every
>> advertised PFN up front. Sparse pmem images and workloads that only use the
>> DAX direct-access path may never need writable per-PFN state for most of
>> that range, but still pay the memory and initialization cost.
>> 
>> Add an opt-in dev_pagemap mode that populates FS-DAX vmemmap PTEs from a
>> shared read-only metadata page. The shared page is initialized with the
>> common ZONE_DEVICE and dev_pagemap state, so every PFN still has a valid
>> struct page representation while private metadata allocation is deferred.
>> 
>> This relies on sizeof(struct page) being a power of two, so each vmemmap
>> page contains a naturally aligned and repeatable set of struct page slots.
>> It also requires architecture support for runtime vmemmap remapping,
>> because shared mappings must be replaced with private writable pages before
>> a PFN can enter userspace mappings.
>> 
>> The initial implementation is deliberately limited to a single
>> memory-block-aligned range. That is not a fundamental requirement, but keeps
>> the registration and teardown paths simple; support for multiple ranges or
>> less strict alignment can be added later.
>> 
>> Provide vmemmap_materialize_page() to replace shared mappings in the
>> requested metadata range with private writable copies. A later patch will
>> call it from the FS-DAX fault path.
>> 
>> No caller enables the mode yet.
>> 
>> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
>> ---
>>  include/linux/memremap.h | 11 ++++++-
>>  mm/memremap.c            | 38 ++++++++++++++++++++++--
>>  mm/mm_init.c             | 11 +++++++
>>  mm/sparse-vmemmap.c      | 64 +++++++++++++++++++++++++++++++++++++---
>>  4 files changed, 116 insertions(+), 8 deletions(-)
>> 
>> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
>> index e3c2ccf872a8..21c9b6aeef67 100644
>> --- a/include/linux/memremap.h
>> +++ b/include/linux/memremap.h
>> @@ -9,6 +9,7 @@
>>    struct resource;
>>  struct device;
>> +struct page;
>>    /**
>>   * struct vmem_altmap - pre-allocated storage for vmemmap_populate
>> @@ -108,7 +109,8 @@ struct dev_pagemap_ops {
>>   	void (*folio_split)(struct folio *head, struct folio *tail);
>>  };
>>  -#define PGMAP_ALTMAP_VALID (1 << 0)
>> +#define PGMAP_ALTMAP_VALID BIT(0)
>> +#define PGMAP_VMEMMAP_OPTIMIZATION BIT(1)
> 
> I liked the overall idea.
> 
> Minor naming suggestion I have:
> 
> 'PGMAP_VMEMMAP_OPTIMIZATION' feel too generic to me.
> 
> Maybe something on the lines to reflect the actual optimization:
> 
> |PGMAP_SHARED_VMEMMAP or PGMAP_VMEMMAP_ON_DEMAND or some_other_name?|

Maybe PGMAP_VMEMMAP_SHARED? It describes the shared vmemmap backing
more precisely. I prefer SHARED over ON_DEMAND.

If you are OK with this, I will keep it for the next version.

Thanks,
Muchun