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

["Gupta, Pankaj" <pankaj.gupta@amd.com>]

>>> 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.

Yes, PGMAP_VMEMMAP_SHARED sounds better.

Thanks,

Pankaj