Currently, when memory is hot-plugged or hot-removed the accounting is
done based on the assumption that memmap is allocated from the same node
as the hot-plugged/hot-removed memory, which is not always the case.

In addition, there are challenges with keeping the node id of the memory
that is being remove to the time when memmap accounting is actually
performed: since this is done after remove_pfn_range_from_zone(), and
also after remove_memory_block_devices(). Meaning that we cannot use
pgdat nor walking though memblocks to get the nid.

Given all of that, account the memmap overhead system wide instead.

Reported-by: Yi Zhang <yi.zhang@redhat.com>
Closes: https://lore.kernel.org/linux-cxl/CAHj4cs9Ax1=CoJkgBGP_+sNu6-6=6v=_L-ZBZY0bVLD3wUWZQg@mail.gmail.com
Reported-by: Alison Schofield <alison.schofield@intel.com>
Closes: https://lore.kernel.org/linux-mm/Zq0tPd2h6alFz8XF@aschofie-mobl2/#t

Fixes: 15995a352474 ("mm: report per-page metadata information")
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
---
 include/linux/mmzone.h        |  2 --
 include/linux/vm_event_item.h |  2 ++
 include/linux/vmstat.h        |  7 ++++--
 mm/hugetlb_vmemmap.c          |  8 +++----
 mm/mm_init.c                  |  3 +--
 mm/page_alloc.c               |  1 -
 mm/page_ext.c                 | 15 ++++--------
 mm/sparse-vmemmap.c           | 11 ++++-----
 mm/sparse.c                   |  5 ++--
 mm/vmstat.c                   | 45 ++++++++++++++++-------------------
 10 files changed, 44 insertions(+), 55 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 41458892bc8a..1dc6248feb83 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -220,8 +220,6 @@ enum node_stat_item {
 	PGDEMOTE_KSWAPD,
 	PGDEMOTE_DIRECT,
 	PGDEMOTE_KHUGEPAGED,
-	NR_MEMMAP, /* page metadata allocated through buddy allocator */
-	NR_MEMMAP_BOOT, /* page metadata allocated through boot allocator */
 	NR_VM_NODE_STAT_ITEMS
 };
 
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index 747943bc8cc2..89d091d5da19 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -154,6 +154,8 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
 		VMA_LOCK_RETRY,
 		VMA_LOCK_MISS,
 #endif
+		NR_MEMMAP, /* page metadata allocated through buddy allocator */
+		NR_MEMMAP_BOOT, /* page metadata allocated through boot allocator */
 		NR_VM_EVENT_ITEMS
 };
 
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index 23cd17942036..b978df3992f2 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -625,7 +625,10 @@ static inline void lruvec_stat_sub_folio(struct folio *folio,
 	lruvec_stat_mod_folio(folio, idx, -folio_nr_pages(folio));
 }
 
-void __meminit mod_node_early_perpage_metadata(int nid, long delta);
-void __meminit store_early_perpage_metadata(void);
+void mod_memmap_boot(long delta);
+static inline void mod_memmap(long delta)
+{
+	count_vm_events(NR_MEMMAP, delta);
+}
 
 #endif /* _LINUX_VMSTAT_H */
diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
index 70027869d844..60a5faa1f341 100644
--- a/mm/hugetlb_vmemmap.c
+++ b/mm/hugetlb_vmemmap.c
@@ -185,10 +185,10 @@ static int vmemmap_remap_range(unsigned long start, unsigned long end,
 static inline void free_vmemmap_page(struct page *page)
 {
 	if (PageReserved(page)) {
-		mod_node_page_state(page_pgdat(page), NR_MEMMAP_BOOT, -1);
+		mod_memmap_boot(-1);
 		free_bootmem_page(page);
 	} else {
-		mod_node_page_state(page_pgdat(page), NR_MEMMAP, -1);
+		mod_memmap(-1);
 		__free_page(page);
 	}
 }
@@ -341,7 +341,7 @@ static int vmemmap_remap_free(unsigned long start, unsigned long end,
 		copy_page(page_to_virt(walk.reuse_page),
 			  (void *)walk.reuse_addr);
 		list_add(&walk.reuse_page->lru, vmemmap_pages);
-		mod_node_page_state(NODE_DATA(nid), NR_MEMMAP, 1);
+		mod_memmap(1);
 	}
 
 	/*
@@ -396,7 +396,7 @@ static int alloc_vmemmap_page_list(unsigned long start, unsigned long end,
 			goto out;
 		list_add(&page->lru, list);
 	}
-	mod_node_page_state(NODE_DATA(nid), NR_MEMMAP, nr_pages);
+	mod_memmap(nr_pages);
 
 	return 0;
 out:
diff --git a/mm/mm_init.c b/mm/mm_init.c
index 75c3bd42799b..29677274e74e 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -1623,8 +1623,7 @@ static void __init alloc_node_mem_map(struct pglist_data *pgdat)
 		panic("Failed to allocate %ld bytes for node %d memory map\n",
 		      size, pgdat->node_id);
 	pgdat->node_mem_map = map + offset;
-	mod_node_early_perpage_metadata(pgdat->node_id,
-					DIV_ROUND_UP(size, PAGE_SIZE));
+	mod_memmap_boot(DIV_ROUND_UP(size, PAGE_SIZE));
 	pr_debug("%s: node %d, pgdat %08lx, node_mem_map %08lx\n",
 		 __func__, pgdat->node_id, (unsigned long)pgdat,
 		 (unsigned long)pgdat->node_mem_map);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 28f80daf5c04..875d76e8684a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5755,7 +5755,6 @@ void __init setup_per_cpu_pageset(void)
 	for_each_online_pgdat(pgdat)
 		pgdat->per_cpu_nodestats =
 			alloc_percpu(struct per_cpu_nodestat);
-	store_early_perpage_metadata();
 }
 
 __meminit void zone_pcp_init(struct zone *zone)
diff --git a/mm/page_ext.c b/mm/page_ext.c
index 962d45eee1f8..a4b485b39330 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -214,8 +214,7 @@ static int __init alloc_node_page_ext(int nid)
 		return -ENOMEM;
 	NODE_DATA(nid)->node_page_ext = base;
 	total_usage += table_size;
-	mod_node_page_state(NODE_DATA(nid), NR_MEMMAP_BOOT,
-			    DIV_ROUND_UP(table_size, PAGE_SIZE));
+	mod_memmap_boot(DIV_ROUND_UP(table_size, PAGE_SIZE));
 	return 0;
 }
 
@@ -275,10 +274,8 @@ static void *__meminit alloc_page_ext(size_t size, int nid)
 	else
 		addr = vzalloc_node(size, nid);
 
-	if (addr) {
-		mod_node_page_state(NODE_DATA(nid), NR_MEMMAP,
-				    DIV_ROUND_UP(size, PAGE_SIZE));
-	}
+	if (addr)
+		mod_memmap(DIV_ROUND_UP(size, PAGE_SIZE));
 
 	return addr;
 }
@@ -330,14 +327,12 @@ static void free_page_ext(void *addr)
 	if (is_vmalloc_addr(addr)) {
 		page = vmalloc_to_page(addr);
 		pgdat = page_pgdat(page);
-		mod_node_page_state(pgdat, NR_MEMMAP,
-				    -1L * (DIV_ROUND_UP(table_size, PAGE_SIZE)));
+		mod_memmap(-1L * (DIV_ROUND_UP(table_size, PAGE_SIZE)));
 		vfree(addr);
 	} else {
 		page = virt_to_page(addr);
 		pgdat = page_pgdat(page);
-		mod_node_page_state(pgdat, NR_MEMMAP,
-				    -1L * (DIV_ROUND_UP(table_size, PAGE_SIZE)));
+		mod_memmap(-1L * (DIV_ROUND_UP(table_size, PAGE_SIZE)));
 		BUG_ON(PageReserved(page));
 		kmemleak_free(addr);
 		free_pages_exact(addr, table_size);
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 1dda6c53370b..307f6fe83598 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -469,13 +469,10 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn,
 	if (r < 0)
 		return NULL;
 
-	if (system_state == SYSTEM_BOOTING) {
-		mod_node_early_perpage_metadata(nid, DIV_ROUND_UP(end - start,
-								  PAGE_SIZE));
-	} else {
-		mod_node_page_state(NODE_DATA(nid), NR_MEMMAP,
-				    DIV_ROUND_UP(end - start, PAGE_SIZE));
-	}
+	if (system_state == SYSTEM_BOOTING)
+		mod_memmap_boot(DIV_ROUND_UP(end - start, PAGE_SIZE));
+	else
+		mod_memmap(DIV_ROUND_UP(end - start, PAGE_SIZE));
 
 	return pfn_to_page(pfn);
 }
diff --git a/mm/sparse.c b/mm/sparse.c
index e4b830091d13..9cc80ba1f7c1 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -463,7 +463,7 @@ static void __init sparse_buffer_init(unsigned long size, int nid)
 	sparsemap_buf = memmap_alloc(size, section_map_size(), addr, nid, true);
 	sparsemap_buf_end = sparsemap_buf + size;
 #ifndef CONFIG_SPARSEMEM_VMEMMAP
-	mod_node_early_perpage_metadata(nid, DIV_ROUND_UP(size, PAGE_SIZE));
+	mod_memmap_boot(DIV_ROUND_UP(size, PAGE_SIZE));
 #endif
 }
 
@@ -643,8 +643,7 @@ static void depopulate_section_memmap(unsigned long pfn, unsigned long nr_pages,
 	unsigned long start = (unsigned long) pfn_to_page(pfn);
 	unsigned long end = start + nr_pages * sizeof(struct page);
 
-	mod_node_page_state(page_pgdat(pfn_to_page(pfn)), NR_MEMMAP,
-			    -1L * (DIV_ROUND_UP(end - start, PAGE_SIZE)));
+	mod_memmap(-1L * (DIV_ROUND_UP(end - start, PAGE_SIZE)));
 	vmemmap_free(start, end, altmap);
 }
 static void free_map_bootmem(struct page *memmap)
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 04a1cb6cc636..7bee38347f10 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1255,8 +1255,6 @@ const char * const vmstat_text[] = {
 	"pgdemote_kswapd",
 	"pgdemote_direct",
 	"pgdemote_khugepaged",
-	"nr_memmap",
-	"nr_memmap_boot",
 	/* enum writeback_stat_item counters */
 	"nr_dirty_threshold",
 	"nr_dirty_background_threshold",
@@ -1417,6 +1415,8 @@ const char * const vmstat_text[] = {
 	"vma_lock_retry",
 	"vma_lock_miss",
 #endif
+	"nr_memmap",
+	"nr_memmap_boot",
 #endif /* CONFIG_VM_EVENT_COUNTERS || CONFIG_MEMCG */
 };
 #endif /* CONFIG_PROC_FS || CONFIG_SYSFS || CONFIG_NUMA || CONFIG_MEMCG */
@@ -2117,6 +2117,24 @@ static int vmstat_cpu_dead(unsigned int cpu)
 
 #endif
 
+/* nr_memmap_boot that is used prior to setup_per_cpu_areas() call */
+static atomic_long_t early_memmap_boot;
+static bool early_memmap_boot_finished;
+
+void mod_memmap_boot(long delta)
+{
+	if (early_memmap_boot_finished)
+		count_vm_events(NR_MEMMAP_BOOT, delta);
+	else
+		atomic_long_add(delta, &early_memmap_boot);
+}
+
+static void __init finish_early_memmap_boot(void)
+{
+	early_memmap_boot_finished = true;
+	mod_memmap_boot(atomic_long_read(&early_memmap_boot));
+}
+
 struct workqueue_struct *mm_percpu_wq;
 
 void __init init_mm_internals(void)
@@ -2149,6 +2167,7 @@ void __init init_mm_internals(void)
 	proc_create_seq("vmstat", 0444, NULL, &vmstat_op);
 	proc_create_seq("zoneinfo", 0444, NULL, &zoneinfo_op);
 #endif
+	finish_early_memmap_boot();
 }
 
 #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_COMPACTION)
@@ -2285,25 +2304,3 @@ static int __init extfrag_debug_init(void)
 module_init(extfrag_debug_init);
 
 #endif
-
-/*
- * Page metadata size (struct page and page_ext) in pages
- */
-static unsigned long early_perpage_metadata[MAX_NUMNODES] __meminitdata;
-
-void __meminit mod_node_early_perpage_metadata(int nid, long delta)
-{
-	early_perpage_metadata[nid] += delta;
-}
-
-void __meminit store_early_perpage_metadata(void)
-{
-	int nid;
-	struct pglist_data *pgdat;
-
-	for_each_online_pgdat(pgdat) {
-		nid = pgdat->node_id;
-		mod_node_page_state(NODE_DATA(nid), NR_MEMMAP_BOOT,
-				    early_perpage_metadata[nid]);
-	}
-}
-- 
2.46.0.76.ge559c4bf1a-goog

> On Aug 8, 2024, at 05:19, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> 
> Currently, when memory is hot-plugged or hot-removed the accounting is
> done based on the assumption that memmap is allocated from the same node
> as the hot-plugged/hot-removed memory, which is not always the case.
> 
> In addition, there are challenges with keeping the node id of the memory
> that is being remove to the time when memmap accounting is actually
> performed: since this is done after remove_pfn_range_from_zone(), and
> also after remove_memory_block_devices(). Meaning that we cannot use
> pgdat nor walking though memblocks to get the nid.
> 
> Given all of that, account the memmap overhead system wide instead.

Hi Pasha,

You've changed it to vm event mechanism. But I found a comment (below) say
"Counters should only be incremented". I do not know why it has such a rule
sice 2006. Now the rule should be changed, is there any effect to users of
/proc/vmstat?

/*
 * Light weight per cpu counter implementation.
 *
 * Counters should only be incremented and no critical kernel component
 * should rely on the counter values.
 *
 * Counters are handled completely inline. On many platforms the code
 * generated will simply be the increment of a global address.
 */

Muchun,
Thanks.

On Wed, Aug 7, 2024 at 10:59 PM Muchun Song <muchun.song@linux.dev> wrote:
>
>
>
> > On Aug 8, 2024, at 05:19, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> >
> > Currently, when memory is hot-plugged or hot-removed the accounting is
> > done based on the assumption that memmap is allocated from the same node
> > as the hot-plugged/hot-removed memory, which is not always the case.
> >
> > In addition, there are challenges with keeping the node id of the memory
> > that is being remove to the time when memmap accounting is actually
> > performed: since this is done after remove_pfn_range_from_zone(), and
> > also after remove_memory_block_devices(). Meaning that we cannot use
> > pgdat nor walking though memblocks to get the nid.
> >
> > Given all of that, account the memmap overhead system wide instead.
>
> Hi Pasha,
>
> You've changed it to vm event mechanism. But I found a comment (below) say
> "CONFIG_VM_EVENT_COUNTERS". I do not know why it has such a rule
> sice 2006. Now the rule should be changed, is there any effect to users of
> /proc/vmstat?

There should not be any effect on the users of the /proc/vmstat, the
values for nr_memap and nr_memmap_boot before and after are still in
/proc/vmstat under the same names.

>
> /*
>  * Light weight per cpu counter implementation.
>  *
>  * Counters should only be incremented and no critical kernel component
>  * should rely on the counter values.
>  *
>  * Counters are handled completely inline. On many platforms the code
>  * generated will simply be the increment of a global address.

Thank you for noticing this. Based on my digging, it looks like this
comment means that the increment only produces the most efficient code
on some architectures (i.e. i386, ia64):

Here is the original commit message from 6/30/06:
f8891e5e1f93a1 [PATCH] Lightweight event counters

 Relevant information:
  The implementation of these counters is through inline code that hopefully
  results in only a single instruction increment instruction being emitted
  (i386, x86_64) or in the increment being hidden though instruction
  concurrency (EPIC architectures such as ia64 can get that done).

My patch does not change anything in other places where vm_events are
used, so it won't introduce performance regression anywhere. Memmap,
increment and decrement can happen based on the value of delta. I have
tested, and it works correctly. Perhaps we should update the comment.

Pasha

On Wed, Aug 7, 2024 at 9:04 PM Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
>
> On Wed, Aug 7, 2024 at 10:59 PM Muchun Song <muchun.song@linux.dev> wrote:
> >
> >
> >
> > > On Aug 8, 2024, at 05:19, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> > >
> > > Currently, when memory is hot-plugged or hot-removed the accounting is
> > > done based on the assumption that memmap is allocated from the same node
> > > as the hot-plugged/hot-removed memory, which is not always the case.
> > >
> > > In addition, there are challenges with keeping the node id of the memory
> > > that is being remove to the time when memmap accounting is actually
> > > performed: since this is done after remove_pfn_range_from_zone(), and
> > > also after remove_memory_block_devices(). Meaning that we cannot use
> > > pgdat nor walking though memblocks to get the nid.
> > >
> > > Given all of that, account the memmap overhead system wide instead.
> >
> > Hi Pasha,
> >
> > You've changed it to vm event mechanism. But I found a comment (below) say
> > "CONFIG_VM_EVENT_COUNTERS". I do not know why it has such a rule
> > sice 2006. Now the rule should be changed, is there any effect to users of
> > /proc/vmstat?
>
> There should not be any effect on the users of the /proc/vmstat, the
> values for nr_memap and nr_memmap_boot before and after are still in
> /proc/vmstat under the same names.
>
> >
> > /*
> >  * Light weight per cpu counter implementation.
> >  *
> >  * Counters should only be incremented and no critical kernel component
> >  * should rely on the counter values.
> >  *
> >  * Counters are handled completely inline. On many platforms the code
> >  * generated will simply be the increment of a global address.
>
> Thank you for noticing this. Based on my digging, it looks like this
> comment means that the increment only produces the most efficient code
> on some architectures (i.e. i386, ia64):
>
> Here is the original commit message from 6/30/06:
> f8891e5e1f93a1 [PATCH] Lightweight event counters
>
>  Relevant information:
>   The implementation of these counters is through inline code that hopefully
>   results in only a single instruction increment instruction being emitted
>   (i386, x86_64) or in the increment being hidden though instruction
>   concurrency (EPIC architectures such as ia64 can get that done).
>
> My patch does not change anything in other places where vm_events are
> used, so it won't introduce performance regression anywhere. Memmap,
> increment and decrement can happen based on the value of delta. I have
> tested, and it works correctly. Perhaps we should update the comment.

I think there may be a semantic inconsistency here.

I am not so sure about this code, but for memcg stats, there is a
semantic distinction between stat (or state) and event.

Per-memcg events (which are a subset of NR_VM_EVENT_ITEMS) are
basically counting the number of times a certain event happened (e.g.
PGFAULT). This naturally cannot be decremented because the number of
page faults that happened cannot decrease.

Per-memcg state are things that represent the current state of the
system (e.g. NR_SWAPCACHE). This can naturally go up or down.

It seems like the code here follows the same semantics, and this
change breaks that. Also, now these stats depend on
CONFIG_VM_EVENT_COUNTERS .

Looking at NR_VMSTAT_ITEMS, it looks like it's composed of:
NR_VM_ZONE_STAT_ITEMS,
NR_VM_NUMA_EVENT_ITEMS,
NR_VM_NODE_STAT_ITEMS,
NR_VM_WRITEBACK_STAT_ITEMS,
NR_VM_EVENT_ITEMS (with CONFIG_VM_EVENT_COUNTERS)

Semantically, the memmap stats do not fit into any of the above
categories if we do not want them to be per-node. Maybe they should
have their own category like NR_VM_WRITEBACK_STAT_ITEMS, or maybe we
should consolidate both of them into a global stat items category
(e.g. NR_VM_STAT_ITEMS)?

On Thu, Aug 8, 2024 at 1:36 AM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> On Wed, Aug 7, 2024 at 9:04 PM Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> >
> > On Wed, Aug 7, 2024 at 10:59 PM Muchun Song <muchun.song@linux.dev> wrote:
> > >
> > >
> > >
> > > > On Aug 8, 2024, at 05:19, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> > > >
> > > > Currently, when memory is hot-plugged or hot-removed the accounting is
> > > > done based on the assumption that memmap is allocated from the same node
> > > > as the hot-plugged/hot-removed memory, which is not always the case.
> > > >
> > > > In addition, there are challenges with keeping the node id of the memory
> > > > that is being remove to the time when memmap accounting is actually
> > > > performed: since this is done after remove_pfn_range_from_zone(), and
> > > > also after remove_memory_block_devices(). Meaning that we cannot use
> > > > pgdat nor walking though memblocks to get the nid.
> > > >
> > > > Given all of that, account the memmap overhead system wide instead.
> > >
> > > Hi Pasha,
> > >
> > > You've changed it to vm event mechanism. But I found a comment (below) say
> > > "CONFIG_VM_EVENT_COUNTERS". I do not know why it has such a rule
> > > sice 2006. Now the rule should be changed, is there any effect to users of
> > > /proc/vmstat?
> >
> > There should not be any effect on the users of the /proc/vmstat, the
> > values for nr_memap and nr_memmap_boot before and after are still in
> > /proc/vmstat under the same names.
> >
> > >
> > > /*
> > >  * Light weight per cpu counter implementation.
> > >  *
> > >  * Counters should only be incremented and no critical kernel component
> > >  * should rely on the counter values.
> > >  *
> > >  * Counters are handled completely inline. On many platforms the code
> > >  * generated will simply be the increment of a global address.
> >
> > Thank you for noticing this. Based on my digging, it looks like this
> > comment means that the increment only produces the most efficient code
> > on some architectures (i.e. i386, ia64):
> >
> > Here is the original commit message from 6/30/06:
> > f8891e5e1f93a1 [PATCH] Lightweight event counters
> >
> >  Relevant information:
> >   The implementation of these counters is through inline code that hopefully
> >   results in only a single instruction increment instruction being emitted
> >   (i386, x86_64) or in the increment being hidden though instruction
> >   concurrency (EPIC architectures such as ia64 can get that done).
> >
> > My patch does not change anything in other places where vm_events are
> > used, so it won't introduce performance regression anywhere. Memmap,
> > increment and decrement can happen based on the value of delta. I have
> > tested, and it works correctly. Perhaps we should update the comment.
>
> I think there may be a semantic inconsistency here.
>
> I am not so sure about this code, but for memcg stats, there is a
> semantic distinction between stat (or state) and event.
>
> Per-memcg events (which are a subset of NR_VM_EVENT_ITEMS) are
> basically counting the number of times a certain event happened (e.g.
> PGFAULT). This naturally cannot be decremented because the number of
> page faults that happened cannot decrease.

From what I can tell, for users, there is no difference, at the end
everything is provided through /proc/vmstat, depending on a counter
name they can either only-grow or go up and down. The separation is an
internal only concept.

> Per-memcg state are things that represent the current state of the
> system (e.g. NR_SWAPCACHE). This can naturally go up or down.
>
> It seems like the code here follows the same semantics, and this
> change breaks that. Also, now these stats depend on
> CONFIG_VM_EVENT_COUNTERS .

Yes, nr_memmap_* won't show up without this config with my change.

>
> Looking at NR_VMSTAT_ITEMS, it looks like it's composed of:
> NR_VM_ZONE_STAT_ITEMS,
> NR_VM_NUMA_EVENT_ITEMS,
> NR_VM_NODE_STAT_ITEMS,
> NR_VM_WRITEBACK_STAT_ITEMS,
> NR_VM_EVENT_ITEMS (with CONFIG_VM_EVENT_COUNTERS)
> Semantically, the memmap stats do not fit into any of the above
> categories if we do not want them to be per-node. Maybe they should
> have their own category like NR_VM_WRITEBACK_STAT_ITEMS, or maybe we
> should consolidate both of them into a global stat items category
> (e.g. NR_VM_STAT_ITEMS)?

I like the idea of renaming NR_VM_WRITEBACK_STAT_ITEMS with
NR_GLOBAL_STAT_ITEMS, and add counters there, let me do that.

Pasha