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<[email protected]>
---
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
