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

[Gupta, Pankaj]

> > > 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@xxxxxxxxxxxxx>
> > > ---
> > >   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