mm/demotion: Memory tiers and demotion

In the current kernel, memory tiers are defined implicitly via a demotion path relationship between NUMA nodes, which is created during the kernel initialization and updated when a NUMA node is hot-added or hot-removed. The current implementation puts all nodes with CPU into the highest tier, and builds the tier hierarchy tier-by-tier by establishing the per-node demotion targets based on the distances between nodes.

This current memory tier kernel implementation needs to be improved for several important use cases,

The current tier initialization code always initializes each memory-only NUMA node into a lower tier. But a memory-only NUMA node may have a high performance memory device (e.g. a DRAM-backed memory-only node on a virtual machine) that should be put into a higher tier.

The current tier hierarchy always puts CPU nodes into the top tier. But on a system with HBM or GPU devices, the memory-only NUMA nodes mapping these devices should be in the top tier, and DRAM nodes with CPUs are better to be placed into the next lower tier.

With current kernel higher tier node can only be demoted to nodes with shortest distance on the next lower tier as defined by the demotion path, not any other node from any lower tier. This strict, demotion order does not work in all use cases (e.g. some use cases may want to allow cross-socket demotion to another node in the same demotion tier as a fallback when the preferred demotion node is out of space), This demotion order is also inconsistent with the page allocation fallback order when all the nodes in a higher tier are out of space: The page allocation can fall back to any node from any lower tier, whereas the demotion order doesn't allow that.

This patch series address the above by defining memory tiers explicitly.

Linux kernel presents memory devices as NUMA nodes and each memory device is of a specific type. The memory type of a device is represented by its abstract distance. A memory tier corresponds to a range of abstract distance. This allows for classifying memory devices with a specific performance range into a memory tier.

This patch configures the range/chunk size to be 128. The default DRAM abstract distance is 512. We can have 4 memory tiers below the default DRAM abstract distance which cover the range 0 - 127, 127 - 255, 256- 383, 384 - 511. Slower memory devices like persistent memory will have abstract distance below the default DRAM level and hence will be placed in these 4 lower tiers.

A kernel parameter is provided to override the default memory tier.

Link https://lore.kernel.org/linux-mm/CAAPL-u9Wv+nH1VOZTj=9p9S70Y3Qz3+63EkqncRDdHfubsrjfw@mail.gmail.com open here

Link https://lore.kernel.org/linux-mm/[email protected] open here

Signed-off-by Jagdish Gediya <[email protected]>

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 include/linux/memory-tiers.h |  17 ++++++
 mm/Makefile                  |   1 +
 mm/memory-tiers.c            | 102 +++++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+)
 create mode 100644 include/linux/memory-tiers.h
 create mode 100644 mm/memory-tiers.c

include/linux/memory-tiers.h new file +17 -0

new file mode 100644
index 000000000000..8d7884b7a3f0
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MEMORY_TIERS_H
+#define _LINUX_MEMORY_TIERS_H
+
+/*
+ * Each tier cover a abstrace distance chunk size of 128
+ */
+#define MEMTIER_CHUNK_BITS	7
+#define MEMTIER_CHUNK_SIZE	(1 << MEMTIER_CHUNK_BITS)
+/*
+ * For now let's have 4 memory tier below default DRAM tier.
+ */
+#define MEMTIER_ADISTANCE_DRAM	(1 << (MEMTIER_CHUNK_BITS + 2))
+/* leave one tier below this slow pmem */
+#define MEMTIER_ADISTANCE_PMEM	(1 << MEMTIER_CHUNK_BITS)
+
+#endif  /* _LINUX_MEMORY_TIERS_H */

mm/Makefile +1 -0

index 6f9ffa968a1a..d30acebc2164 100644
@@ -92,6 +92,7 @@ obj-$(CONFIG_KFENCE) += kfence/
 obj-$(CONFIG_FAILSLAB) += failslab.o
 obj-$(CONFIG_MEMTEST)		+= memtest.o
 obj-$(CONFIG_MIGRATION) += migrate.o
+obj-$(CONFIG_NUMA) += memory-tiers.o
 obj-$(CONFIG_DEVICE_MIGRATION) += migrate_device.o
 obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += huge_memory.o khugepaged.o
 obj-$(CONFIG_PAGE_COUNTER) += page_counter.o

mm/memory-tiers.c new file +102 -0

new file mode 100644
index 000000000000..01cfd514c192
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/types.h>
+#include <linux/nodemask.h>
+#include <linux/slab.h>
+#include <linux/lockdep.h>
+#include <linux/memory-tiers.h>
+
+struct memory_tier {
+	/* hierarchy of memory tiers */
+	struct list_head list;
+	/* list of all memory types part of this tier */
+	struct list_head memory_types;
+	/*
+	 * start value of abstract distance. memory tier maps
+	 * an abstract distance  range,
+	 * adistance_start .. adistance_start + MEMTIER_CHUNK_SIZE
+	 */
+	int adistance_start;
+};
+
+struct memory_dev_type {
+	/* list of memory types that are are part of same tier as this type */
+	struct list_head tier_sibiling;
+	/* abstract distance for this specific memory type */
+	int adistance;
+	/* Nodes of same abstract distance */
+	nodemask_t nodes;
+	struct memory_tier *memtier;
+};
+
+static DEFINE_MUTEX(memory_tier_lock);
+static LIST_HEAD(memory_tiers);
+struct memory_dev_type *node_memory_types[MAX_NUMNODES];
+/*
+ * For now let's have 4 memory tier below default DRAM tier.
+ */
+static struct memory_dev_type default_dram_type  = {
+	.adistance = MEMTIER_ADISTANCE_DRAM,
+	.tier_sibiling = LIST_HEAD_INIT(default_dram_type.tier_sibiling),
+};
+
+static struct memory_tier *find_create_memory_tier(struct memory_dev_type *memtype)
+{
+	bool found_slot = false;
+	struct memory_tier *memtier, *new_memtier;
+	int adistance = memtype->adistance;
+	unsigned int memtier_adistance_chunk_size = MEMTIER_CHUNK_SIZE;
+
+	lockdep_assert_held_once(&memory_tier_lock);
+
+	/*
+	 * If the memtype is already part of a memory tier,
+	 * just return that.
+	 */
+	if (memtype->memtier)
+		return memtype->memtier;
+
+	adistance = round_down(adistance, memtier_adistance_chunk_size);
+	list_for_each_entry(memtier, &memory_tiers, list) {
+		if (adistance == memtier->adistance_start) {
+			memtype->memtier = memtier;
+			list_add(&memtype->tier_sibiling, &memtier->memory_types);
+			return memtier;
+		} else if (adistance < memtier->adistance_start) {
+			found_slot = true;
+			break;
+		}
+	}
+
+	new_memtier = kzalloc(sizeof(struct memory_tier), GFP_KERNEL);
+	if (!new_memtier)
+		return ERR_PTR(-ENOMEM);
+
+	new_memtier->adistance_start = adistance;
+	INIT_LIST_HEAD(&new_memtier->list);
+	INIT_LIST_HEAD(&new_memtier->memory_types);
+	if (found_slot)
+		list_add_tail(&new_memtier->list, &memtier->list);
+	else
+		list_add_tail(&new_memtier->list, &memory_tiers);
+	memtype->memtier = new_memtier;
+	list_add(&memtype->tier_sibiling, &new_memtier->memory_types);
+	return new_memtier;
+}
+
+static int __init memory_tier_init(void)
+{
+	struct memory_tier *memtier;
+
+	mutex_lock(&memory_tier_lock);
+	/* CPU only nodes are not part of memory tiers. */
+	default_dram_type.nodes = node_states[N_MEMORY];
+
+	memtier = find_create_memory_tier(&default_dram_type);
+	if (IS_ERR(memtier))
+		panic("%s() failed to register memory tier: %ld\n",
+		      __func__, PTR_ERR(memtier));
+	mutex_unlock(&memory_tier_lock);
+
+	return 0;
+}
+subsys_initcall(memory_tier_init);

Quoted 38 lines · Aneesh Kumar K.V

In the current kernel, memory tiers are defined implicitly via a demotion path relationship between NUMA nodes, which is created during the kernel initialization and updated when a NUMA node is hot-added or hot-removed. The current implementation puts all nodes with CPU into the highest tier, and builds the tier hierarchy tier-by-tier by establishing the per-node demotion targets based on the distances between nodes.

This current memory tier kernel implementation needs to be improved for several important use cases,

The current tier initialization code always initializes each memory-only NUMA node into a lower tier. But a memory-only NUMA node may have a high performance memory device (e.g. a DRAM-backed memory-only node on a virtual machine) that should be put into a higher tier.

The current tier hierarchy always puts CPU nodes into the top tier. But on a system with HBM or GPU devices, the memory-only NUMA nodes mapping these devices should be in the top tier, and DRAM nodes with CPUs are better to be placed into the next lower tier.

With current kernel higher tier node can only be demoted to nodes with shortest distance on the next lower tier as defined by the demotion path, not any other node from any lower tier. This strict, demotion order does not work in all use cases (e.g. some use cases may want to allow cross-socket demotion to another node in the same demotion tier as a fallback when the preferred demotion node is out of space), This demotion order is also inconsistent with the page allocation fallback order when all the nodes in a higher tier are out of space: The page allocation can fall back to any node from any lower tier, whereas the demotion order doesn't allow that.

This patch series address the above by defining memory tiers explicitly.

Linux kernel presents memory devices as NUMA nodes and each memory device is of a specific type. The memory type of a device is represented by its abstract distance. A memory tier corresponds to a range of abstract distance. This allows for classifying memory devices with a specific performance range into a memory tier.

Quoted 5 lines

This patch configures the range/chunk size to be 128. The default DRAM abstract distance is 512. We can have 4 memory tiers below the default DRAM abstract distance which cover the range 0 - 127, 127 - 255, 256- 383, 384 - 511. Slower memory devices like persistent memory will have abstract distance below the default DRAM level and hence will be placed in these 4 lower tiers.

For abstract distance, the lower value means higher performance, higher value means lower performance. So the abstract distance of PMEM should be smaller than that of DRAM.

Quoted 2 lines

A kernel parameter is provided to override the default memory tier.

Forget to delete?

In the current kernel, memory tiers are defined implicitly via a demotion path relationship between NUMA nodes, which is created during the kernel initialization and updated when a NUMA node is hot-added or hot-removed. The current implementation puts all nodes with CPU into the highest tier, and builds the tier hierarchy tier-by-tier by establishing the per-node demotion targets based on the distances between nodes.

This current memory tier kernel implementation needs to be improved for several important use cases,

The current tier initialization code always initializes each memory-only NUMA node into a lower tier. But a memory-only NUMA node may have a high performance memory device (e.g. a DRAM-backed memory-only node on a virtual machine) that should be put into a higher tier.

The current tier hierarchy always puts CPU nodes into the top tier. But on a system with HBM or GPU devices, the memory-only NUMA nodes mapping these devices should be in the top tier, and DRAM nodes with CPUs are better to be placed into the next lower tier.

With current kernel higher tier node can only be demoted to nodes with shortest distance on the next lower tier as defined by the demotion path, not any other node from any lower tier. This strict, demotion order does not work in all use cases (e.g. some use cases may want to allow cross-socket demotion to another node in the same demotion tier as a fallback when the preferred demotion node is out of space), This demotion order is also inconsistent with the page allocation fallback order when all the nodes in a higher tier are out of space: The page allocation can fall back to any node from any lower tier, whereas the demotion order doesn't allow that.

This patch series address the above by defining memory tiers explicitly.

Linux kernel presents memory devices as NUMA nodes and each memory device is of a specific type. The memory type of a device is represented by its abstract distance. A memory tier corresponds to a range of abstract distance. This allows for classifying memory devices with a specific performance range into a memory tier.

This patch configures the range/chunk size to be 128. The default DRAM abstract distance is 512. We can have 4 memory tiers below the default DRAM abstract distance which cover the range 0 - 127, 127 - 255, 256- 383, 384 - 511. Slower memory devices like persistent memory will have abstract distance below the default DRAM level and hence will be placed in these 4 lower tiers.

A kernel parameter is provided to override the default memory tier.

Link https://lore.kernel.org/linux-mm/CAAPL-u9Wv+nH1VOZTj=9p9S70Y3Qz3+63EkqncRDdHfubsrjfw@mail.gmail.com open here

Link https://lore.kernel.org/linux-mm/[email protected] open here

Signed-off-by Jagdish Gediya <[email protected]>

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 include/linux/memory-tiers.h |  17 ++++++
 mm/Makefile                  |   1 +
 mm/memory-tiers.c            | 102 +++++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+)
 create mode 100644 include/linux/memory-tiers.h
 create mode 100644 mm/memory-tiers.c

include/linux/memory-tiers.h new file +5 -0

new file mode 100644
index 000000000000..8d7884b7a3f0
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MEMORY_TIERS_H
+#define _LINUX_MEMORY_TIERS_H
+
+/*

Quoted 70 lines · Aneesh Kumar K.V

In the current kernel, memory tiers are defined implicitly via a demotion path relationship between NUMA nodes, which is created during the kernel initialization and updated when a NUMA node is hot-added or hot-removed. The current implementation puts all nodes with CPU into the highest tier, and builds the tier hierarchy tier-by-tier by establishing the per-node demotion targets based on the distances between nodes.

This current memory tier kernel implementation needs to be improved for several important use cases,

The current tier initialization code always initializes each memory-only NUMA node into a lower tier. But a memory-only NUMA node may have a high performance memory device (e.g. a DRAM-backed memory-only node on a virtual machine) that should be put into a higher tier.

The current tier hierarchy always puts CPU nodes into the top tier. But on a system with HBM or GPU devices, the memory-only NUMA nodes mapping these devices should be in the top tier, and DRAM nodes with CPUs are better to be placed into the next lower tier.

With current kernel higher tier node can only be demoted to nodes with shortest distance on the next lower tier as defined by the demotion path, not any other node from any lower tier. This strict, demotion order does not work in all use cases (e.g. some use cases may want to allow cross-socket demotion to another node in the same demotion tier as a fallback when the preferred demotion node is out of space), This demotion order is also inconsistent with the page allocation fallback order when all the nodes in a higher tier are out of space: The page allocation can fall back to any node from any lower tier, whereas the demotion order doesn't allow that.

This patch series address the above by defining memory tiers explicitly.

Linux kernel presents memory devices as NUMA nodes and each memory device is of a specific type. The memory type of a device is represented by its abstract distance. A memory tier corresponds to a range of abstract distance. This allows for classifying memory devices with a specific performance range into a memory tier.

This patch configures the range/chunk size to be 128. The default DRAM abstract distance is 512. We can have 4 memory tiers below the default DRAM abstract distance which cover the range 0 - 127, 127 - 255, 256- 383, 384 - 511. Slower memory devices like persistent memory will have abstract distance below the default DRAM level and hence will be placed in these 4 lower tiers.

A kernel parameter is provided to override the default memory tier.

Link https://lore.kernel.org/linux-mm/CAAPL-u9Wv+nH1VOZTj=9p9S70Y3Qz3+63EkqncRDdHfubsrjfw@mail.gmail.com open here

Link https://lore.kernel.org/linux-mm/[email protected] open here

Signed-off-by Jagdish Gediya <[email protected]>

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 include/linux/memory-tiers.h |  17 ++++++
 mm/Makefile                  |   1 +
 mm/memory-tiers.c            | 102 +++++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+)
 create mode 100644 include/linux/memory-tiers.h
 create mode 100644 mm/memory-tiers.c

include/linux/memory-tiers.h new file +5 -0

new file mode 100644
index 000000000000..8d7884b7a3f0
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MEMORY_TIERS_H
+#define _LINUX_MEMORY_TIERS_H
+
+/*

include/linux/memory-tiers.h line 15

Quoted 10 lines

include/linux/memory-tiers.h new file +10 -0

+ * Each tier cover a abstrace distance chunk size of 128
+ */
+#define MEMTIER_CHUNK_BITS	7
+#define MEMTIER_CHUNK_SIZE	(1 << MEMTIER_CHUNK_BITS)
+/*
+ * For now let's have 4 memory tier below default DRAM tier.
+ */
+#define MEMTIER_ADISTANCE_DRAM	(1 << (MEMTIER_CHUNK_BITS + 2))
+/* leave one tier below this slow pmem */
+#define MEMTIER_ADISTANCE_PMEM	(1 << MEMTIER_CHUNK_BITS)

Why is memory type encoded in these values? There is no reason to believe that PMEM is of a lower performance tier than DRAM. Consider high performance energy backed DRAM that makes it "PMEM", consider CXL attached DRAM over a switch topology and constrained links that makes it a lower performance tier than locally attached DRAM. The names should be associated with tiers that indicate their usage. Something like HOT, GENERAL, and COLD. Where, for example, HOT is low capacity high performance compared to the general purpose pool, and COLD is high capacity low performance intended to offload the general purpose tier.

It does not need to be exactly that ontology, but please try to not encode policy meaning behind memory types. There has been explicit effort to avoid that to date because types are fraught for declaring relative performance characteristics, and the relative performance changes based on what memory types are assembled in a given system.

Quoted 92 lines · Dan Williams

Quoted 70 lines · Aneesh Kumar K.V

In the current kernel, memory tiers are defined implicitly via a demotion path relationship between NUMA nodes, which is created during the kernel initialization and updated when a NUMA node is hot-added or hot-removed. The current implementation puts all nodes with CPU into the highest tier, and builds the tier hierarchy tier-by-tier by establishing the per-node demotion targets based on the distances between nodes.

This current memory tier kernel implementation needs to be improved for several important use cases,

The current tier initialization code always initializes each memory-only NUMA node into a lower tier. But a memory-only NUMA node may have a high performance memory device (e.g. a DRAM-backed memory-only node on a virtual machine) that should be put into a higher tier.

The current tier hierarchy always puts CPU nodes into the top tier. But on a system with HBM or GPU devices, the memory-only NUMA nodes mapping these devices should be in the top tier, and DRAM nodes with CPUs are better to be placed into the next lower tier.

With current kernel higher tier node can only be demoted to nodes with shortest distance on the next lower tier as defined by the demotion path, not any other node from any lower tier. This strict, demotion order does not work in all use cases (e.g. some use cases may want to allow cross-socket demotion to another node in the same demotion tier as a fallback when the preferred demotion node is out of space), This demotion order is also inconsistent with the page allocation fallback order when all the nodes in a higher tier are out of space: The page allocation can fall back to any node from any lower tier, whereas the demotion order doesn't allow that.

This patch series address the above by defining memory tiers explicitly.

Linux kernel presents memory devices as NUMA nodes and each memory device is of a specific type. The memory type of a device is represented by its abstract distance. A memory tier corresponds to a range of abstract distance. This allows for classifying memory devices with a specific performance range into a memory tier.

This patch configures the range/chunk size to be 128. The default DRAM abstract distance is 512. We can have 4 memory tiers below the default DRAM abstract distance which cover the range 0 - 127, 127 - 255, 256- 383, 384 - 511. Slower memory devices like persistent memory will have abstract distance below the default DRAM level and hence will be placed in these 4 lower tiers.

A kernel parameter is provided to override the default memory tier.

Link https://lore.kernel.org/linux-mm/CAAPL-u9Wv+nH1VOZTj=9p9S70Y3Qz3+63EkqncRDdHfubsrjfw@mail.gmail.com open here

Link https://lore.kernel.org/linux-mm/[email protected] open here

Signed-off-by Jagdish Gediya <[email protected]>

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 include/linux/memory-tiers.h |  17 ++++++
 mm/Makefile                  |   1 +
 mm/memory-tiers.c            | 102 +++++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+)
 create mode 100644 include/linux/memory-tiers.h
 create mode 100644 mm/memory-tiers.c

include/linux/memory-tiers.h new file +5 -0

new file mode 100644
index 000000000000..8d7884b7a3f0
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MEMORY_TIERS_H
+#define _LINUX_MEMORY_TIERS_H
+
+/*

include/linux/memory-tiers.h line 15

Quoted 10 lines

include/linux/memory-tiers.h new file +10 -0

+ * Each tier cover a abstrace distance chunk size of 128
+ */
+#define MEMTIER_CHUNK_BITS	7
+#define MEMTIER_CHUNK_SIZE	(1 << MEMTIER_CHUNK_BITS)
+/*
+ * For now let's have 4 memory tier below default DRAM tier.
+ */
+#define MEMTIER_ADISTANCE_DRAM	(1 << (MEMTIER_CHUNK_BITS + 2))
+/* leave one tier below this slow pmem */
+#define MEMTIER_ADISTANCE_PMEM	(1 << MEMTIER_CHUNK_BITS)

Why is memory type encoded in these values? There is no reason to believe that PMEM is of a lower performance tier than DRAM. Consider high performance energy backed DRAM that makes it "PMEM", consider CXL attached DRAM over a switch topology and constrained links that makes it a lower performance tier than locally attached DRAM. The names should be associated with tiers that indicate their usage. Something like HOT, GENERAL, and COLD. Where, for example, HOT is low capacity high performance compared to the general purpose pool, and COLD is high capacity low performance intended to offload the general purpose tier.

Quoted 5 lines

It does not need to be exactly that ontology, but please try to not encode policy meaning behind memory types. There has been explicit effort to avoid that to date because types are fraught for declaring relative performance characteristics, and the relative performance changes based on what memory types are assembled in a given system.

Yes. MEMTIER_ADISTANCE_PMEM is something over simplified. That is only used in this very first version to make it as simple as possible.

I think we can come up with something better in the later version. For example, identify the abstract distance of a PMEM device based on HMAT, etc.

And even in this first version, we should put MEMTIER_ADISTANCE_PMEM in dax/kmem.c. Because it's just for that specific type of memory used now, not for all PMEM.

In the current design, memory type is used to report the performance of the hardware, in terms of abstract distance, per Johannes' suggestion.

Which is an abstraction of memory latency and bandwidth. Policy is described via memory tiers. Several memory types may be put in one memory tier. The abstract distance chunk size of the memory tier may be adjusted according to policy.

Quoted 94 lines · Ying

Quoted 92 lines · Dan Williams

Quoted 70 lines · Aneesh Kumar K.V

In the current kernel, memory tiers are defined implicitly via a demotion path relationship between NUMA nodes, which is created during the kernel initialization and updated when a NUMA node is hot-added or hot-removed. The current implementation puts all nodes with CPU into the highest tier, and builds the tier hierarchy tier-by-tier by establishing the per-node demotion targets based on the distances between nodes.

This current memory tier kernel implementation needs to be improved for several important use cases,

The current tier initialization code always initializes each memory-only NUMA node into a lower tier. But a memory-only NUMA node may have a high performance memory device (e.g. a DRAM-backed memory-only node on a virtual machine) that should be put into a higher tier.

The current tier hierarchy always puts CPU nodes into the top tier. But on a system with HBM or GPU devices, the memory-only NUMA nodes mapping these devices should be in the top tier, and DRAM nodes with CPUs are better to be placed into the next lower tier.

With current kernel higher tier node can only be demoted to nodes with shortest distance on the next lower tier as defined by the demotion path, not any other node from any lower tier. This strict, demotion order does not work in all use cases (e.g. some use cases may want to allow cross-socket demotion to another node in the same demotion tier as a fallback when the preferred demotion node is out of space), This demotion order is also inconsistent with the page allocation fallback order when all the nodes in a higher tier are out of space: The page allocation can fall back to any node from any lower tier, whereas the demotion order doesn't allow that.

This patch series address the above by defining memory tiers explicitly.

Linux kernel presents memory devices as NUMA nodes and each memory device is of a specific type. The memory type of a device is represented by its abstract distance. A memory tier corresponds to a range of abstract distance. This allows for classifying memory devices with a specific performance range into a memory tier.

This patch configures the range/chunk size to be 128. The default DRAM abstract distance is 512. We can have 4 memory tiers below the default DRAM abstract distance which cover the range 0 - 127, 127 - 255, 256- 383, 384 - 511. Slower memory devices like persistent memory will have abstract distance below the default DRAM level and hence will be placed in these 4 lower tiers.

A kernel parameter is provided to override the default memory tier.

Link https://lore.kernel.org/linux-mm/CAAPL-u9Wv+nH1VOZTj=9p9S70Y3Qz3+63EkqncRDdHfubsrjfw@mail.gmail.com open here

Link https://lore.kernel.org/linux-mm/[email protected] open here

Signed-off-by Jagdish Gediya <[email protected]>

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 include/linux/memory-tiers.h |  17 ++++++
 mm/Makefile                  |   1 +
 mm/memory-tiers.c            | 102 +++++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+)
 create mode 100644 include/linux/memory-tiers.h
 create mode 100644 mm/memory-tiers.c

include/linux/memory-tiers.h new file +5 -0

new file mode 100644
index 000000000000..8d7884b7a3f0
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MEMORY_TIERS_H
+#define _LINUX_MEMORY_TIERS_H
+
+/*

include/linux/memory-tiers.h line 15

Quoted 10 lines

include/linux/memory-tiers.h new file +10 -0

+ * Each tier cover a abstrace distance chunk size of 128
+ */
+#define MEMTIER_CHUNK_BITS	7
+#define MEMTIER_CHUNK_SIZE	(1 << MEMTIER_CHUNK_BITS)
+/*
+ * For now let's have 4 memory tier below default DRAM tier.
+ */
+#define MEMTIER_ADISTANCE_DRAM	(1 << (MEMTIER_CHUNK_BITS + 2))
+/* leave one tier below this slow pmem */
+#define MEMTIER_ADISTANCE_PMEM	(1 << MEMTIER_CHUNK_BITS)

Why is memory type encoded in these values? There is no reason to believe that PMEM is of a lower performance tier than DRAM. Consider high performance energy backed DRAM that makes it "PMEM", consider CXL attached DRAM over a switch topology and constrained links that makes it a lower performance tier than locally attached DRAM. The names should be associated with tiers that indicate their usage. Something like HOT, GENERAL, and COLD. Where, for example, HOT is low capacity high performance compared to the general purpose pool, and COLD is high capacity low performance intended to offload the general purpose tier.

Quoted 8 lines

Quoted 5 lines

It does not need to be exactly that ontology, but please try to not encode policy meaning behind memory types. There has been explicit effort to avoid that to date because types are fraught for declaring relative performance characteristics, and the relative performance changes based on what memory types are assembled in a given system.

Yes. MEMTIER_ADISTANCE_PMEM is something over simplified. That is only used in this very first version to make it as simple as possible.

I am failing to see the simplicity of using names that convey a performance contract that are invalid depending on the system.

Quoted 3 lines

I think we can come up with something better in the later version. For example, identify the abstract distance of a PMEM device based on HMAT, etc.

Memory tiering has nothing to do with persistence why is PMEM in the name at all?

Quoted 3 lines

And even in this first version, we should put MEMTIER_ADISTANCE_PMEM in dax/kmem.c. Because it's just for that specific type of memory used now, not for all PMEM.

dax/kmem.c also handles HBM and "soft reserved" memory in general. There is also nothing PMEM specific about the device-dax subsystem.

Quoted 2 lines

In the current design, memory type is used to report the performance of the hardware, in terms of abstract distance, per Johannes' suggestion.

That sounds fine, just pick an abstract name, not an explicit memory type.

Quoted 4 lines

Which is an abstraction of memory latency and bandwidth. Policy is described via memory tiers. Several memory types may be put in one memory tier. The abstract distance chunk size of the memory tier may be adjusted according to policy.

That part all sounds good. That said, I do not see the benefit of waiting to run away from these inadequate names.

Quoted 94 lines · Ying

Quoted 92 lines · Dan Williams

Quoted 70 lines · Aneesh Kumar K.V

In the current kernel, memory tiers are defined implicitly via a demotion path relationship between NUMA nodes, which is created during the kernel initialization and updated when a NUMA node is hot-added or hot-removed. The current implementation puts all nodes with CPU into the highest tier, and builds the tier hierarchy tier-by-tier by establishing the per-node demotion targets based on the distances between nodes.

This current memory tier kernel implementation needs to be improved for several important use cases,

The current tier initialization code always initializes each memory-only NUMA node into a lower tier. But a memory-only NUMA node may have a high performance memory device (e.g. a DRAM-backed memory-only node on a virtual machine) that should be put into a higher tier.

The current tier hierarchy always puts CPU nodes into the top tier. But on a system with HBM or GPU devices, the memory-only NUMA nodes mapping these devices should be in the top tier, and DRAM nodes with CPUs are better to be placed into the next lower tier.

With current kernel higher tier node can only be demoted to nodes with shortest distance on the next lower tier as defined by the demotion path, not any other node from any lower tier. This strict, demotion order does not work in all use cases (e.g. some use cases may want to allow cross-socket demotion to another node in the same demotion tier as a fallback when the preferred demotion node is out of space), This demotion order is also inconsistent with the page allocation fallback order when all the nodes in a higher tier are out of space: The page allocation can fall back to any node from any lower tier, whereas the demotion order doesn't allow that.

This patch series address the above by defining memory tiers explicitly.

Linux kernel presents memory devices as NUMA nodes and each memory device is of a specific type. The memory type of a device is represented by its abstract distance. A memory tier corresponds to a range of abstract distance. This allows for classifying memory devices with a specific performance range into a memory tier.

This patch configures the range/chunk size to be 128. The default DRAM abstract distance is 512. We can have 4 memory tiers below the default DRAM abstract distance which cover the range 0 - 127, 127 - 255, 256- 383, 384 - 511. Slower memory devices like persistent memory will have abstract distance below the default DRAM level and hence will be placed in these 4 lower tiers.

A kernel parameter is provided to override the default memory tier.

Link https://lore.kernel.org/linux-mm/CAAPL-u9Wv+nH1VOZTj=9p9S70Y3Qz3+63EkqncRDdHfubsrjfw@mail.gmail.com open here

Link https://lore.kernel.org/linux-mm/[email protected] open here

Signed-off-by Jagdish Gediya <[email protected]>

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 include/linux/memory-tiers.h |  17 ++++++
 mm/Makefile                  |   1 +
 mm/memory-tiers.c            | 102 +++++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+)
 create mode 100644 include/linux/memory-tiers.h
 create mode 100644 mm/memory-tiers.c

include/linux/memory-tiers.h new file +5 -0

new file mode 100644
index 000000000000..8d7884b7a3f0
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MEMORY_TIERS_H
+#define _LINUX_MEMORY_TIERS_H
+
+/*

include/linux/memory-tiers.h line 15

Quoted 10 lines

include/linux/memory-tiers.h new file +10 -0

+ * Each tier cover a abstrace distance chunk size of 128
+ */
+#define MEMTIER_CHUNK_BITS	7
+#define MEMTIER_CHUNK_SIZE	(1 << MEMTIER_CHUNK_BITS)
+/*
+ * For now let's have 4 memory tier below default DRAM tier.
+ */
+#define MEMTIER_ADISTANCE_DRAM	(1 << (MEMTIER_CHUNK_BITS + 2))
+/* leave one tier below this slow pmem */
+#define MEMTIER_ADISTANCE_PMEM	(1 << MEMTIER_CHUNK_BITS)

Why is memory type encoded in these values? There is no reason to believe that PMEM is of a lower performance tier than DRAM. Consider high performance energy backed DRAM that makes it "PMEM", consider CXL attached DRAM over a switch topology and constrained links that makes it a lower performance tier than locally attached DRAM. The names should be associated with tiers that indicate their usage. Something like HOT, GENERAL, and COLD. Where, for example, HOT is low capacity high performance compared to the general purpose pool, and COLD is high capacity low performance intended to offload the general purpose tier.

Quoted 8 lines

Quoted 5 lines

It does not need to be exactly that ontology, but please try to not encode policy meaning behind memory types. There has been explicit effort to avoid that to date because types are fraught for declaring relative performance characteristics, and the relative performance changes based on what memory types are assembled in a given system.

Yes. MEMTIER_ADISTANCE_PMEM is something over simplified. That is only used in this very first version to make it as simple as possible.

I am failing to see the simplicity of using names that convey a performance contract that are invalid depending on the system.

Quoted 3 lines

I think we can come up with something better in the later version. For example, identify the abstract distance of a PMEM device based on HMAT, etc.

Memory tiering has nothing to do with persistence why is PMEM in the name at all?

Quoted 3 lines

And even in this first version, we should put MEMTIER_ADISTANCE_PMEM in dax/kmem.c. Because it's just for that specific type of memory used now, not for all PMEM.

dax/kmem.c also handles HBM and "soft reserved" memory in general. There is also nothing PMEM specific about the device-dax subsystem.

Quoted 2 lines

In the current design, memory type is used to report the performance of the hardware, in terms of abstract distance, per Johannes' suggestion.

That sounds fine, just pick an abstract name, not an explicit memory type.

Quoted 4 lines

Which is an abstraction of memory latency and bandwidth. Policy is described via memory tiers. Several memory types may be put in one memory tier. The abstract distance chunk size of the memory tier may be adjusted according to policy.

That part all sounds good. That said, I do not see the benefit of waiting to run away from these inadequate names.

Quoted 114 lines · Dan Williams

Quoted 94 lines · Ying

Quoted 92 lines · Dan Williams

Quoted 70 lines · Aneesh Kumar K.V

In the current kernel, memory tiers are defined implicitly via a demotion path relationship between NUMA nodes, which is created during the kernel initialization and updated when a NUMA node is hot-added or hot-removed. The current implementation puts all nodes with CPU into the highest tier, and builds the tier hierarchy tier-by-tier by establishing the per-node demotion targets based on the distances between nodes.

This current memory tier kernel implementation needs to be improved for several important use cases,

The current tier initialization code always initializes each memory-only NUMA node into a lower tier. But a memory-only NUMA node may have a high performance memory device (e.g. a DRAM-backed memory-only node on a virtual machine) that should be put into a higher tier.

The current tier hierarchy always puts CPU nodes into the top tier. But on a system with HBM or GPU devices, the memory-only NUMA nodes mapping these devices should be in the top tier, and DRAM nodes with CPUs are better to be placed into the next lower tier.

With current kernel higher tier node can only be demoted to nodes with shortest distance on the next lower tier as defined by the demotion path, not any other node from any lower tier. This strict, demotion order does not work in all use cases (e.g. some use cases may want to allow cross-socket demotion to another node in the same demotion tier as a fallback when the preferred demotion node is out of space), This demotion order is also inconsistent with the page allocation fallback order when all the nodes in a higher tier are out of space: The page allocation can fall back to any node from any lower tier, whereas the demotion order doesn't allow that.

This patch series address the above by defining memory tiers explicitly.

Linux kernel presents memory devices as NUMA nodes and each memory device is of a specific type. The memory type of a device is represented by its abstract distance. A memory tier corresponds to a range of abstract distance. This allows for classifying memory devices with a specific performance range into a memory tier.

This patch configures the range/chunk size to be 128. The default DRAM abstract distance is 512. We can have 4 memory tiers below the default DRAM abstract distance which cover the range 0 - 127, 127 - 255, 256- 383, 384 - 511. Slower memory devices like persistent memory will have abstract distance below the default DRAM level and hence will be placed in these 4 lower tiers.

A kernel parameter is provided to override the default memory tier.

Link https://lore.kernel.org/linux-mm/CAAPL-u9Wv+nH1VOZTj=9p9S70Y3Qz3+63EkqncRDdHfubsrjfw@mail.gmail.com open here

Link https://lore.kernel.org/linux-mm/[email protected] open here

Signed-off-by Jagdish Gediya <[email protected]>

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 include/linux/memory-tiers.h |  17 ++++++
 mm/Makefile                  |   1 +
 mm/memory-tiers.c            | 102 +++++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+)
 create mode 100644 include/linux/memory-tiers.h
 create mode 100644 mm/memory-tiers.c

include/linux/memory-tiers.h new file +5 -0

new file mode 100644
index 000000000000..8d7884b7a3f0
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MEMORY_TIERS_H
+#define _LINUX_MEMORY_TIERS_H
+
+/*

include/linux/memory-tiers.h line 15

Quoted 10 lines

include/linux/memory-tiers.h new file +10 -0

+ * Each tier cover a abstrace distance chunk size of 128
+ */
+#define MEMTIER_CHUNK_BITS	7
+#define MEMTIER_CHUNK_SIZE	(1 << MEMTIER_CHUNK_BITS)
+/*
+ * For now let's have 4 memory tier below default DRAM tier.
+ */
+#define MEMTIER_ADISTANCE_DRAM	(1 << (MEMTIER_CHUNK_BITS + 2))
+/* leave one tier below this slow pmem */
+#define MEMTIER_ADISTANCE_PMEM	(1 << MEMTIER_CHUNK_BITS)

Why is memory type encoded in these values? There is no reason to believe that PMEM is of a lower performance tier than DRAM. Consider high performance energy backed DRAM that makes it "PMEM", consider CXL attached DRAM over a switch topology and constrained links that makes it a lower performance tier than locally attached DRAM. The names should be associated with tiers that indicate their usage. Something like HOT, GENERAL, and COLD. Where, for example, HOT is low capacity high performance compared to the general purpose pool, and COLD is high capacity low performance intended to offload the general purpose tier.

Quoted 8 lines

Quoted 5 lines

It does not need to be exactly that ontology, but please try to not encode policy meaning behind memory types. There has been explicit effort to avoid that to date because types are fraught for declaring relative performance characteristics, and the relative performance changes based on what memory types are assembled in a given system.

Yes. MEMTIER_ADISTANCE_PMEM is something over simplified. That is only used in this very first version to make it as simple as possible.

I am failing to see the simplicity of using names that convey a performance contract that are invalid depending on the system.

Quoted 3 lines

I think we can come up with something better in the later version. For example, identify the abstract distance of a PMEM device based on HMAT, etc.

Memory tiering has nothing to do with persistence why is PMEM in the name at all?

Quoted 6 lines

Quoted 3 lines

And even in this first version, we should put MEMTIER_ADISTANCE_PMEM in dax/kmem.c. Because it's just for that specific type of memory used now, not for all PMEM.

dax/kmem.c also handles HBM and "soft reserved" memory in general. There is also nothing PMEM specific about the device-dax subsystem.

Ah... I see the issue here. For the systems in our hand, dax/kmem.c is used to online PMEM only. Even the "soft reserved" memory is used for PMEM or simulating PMEM too. So to make the code as simple as possible, we treat all memory devices onlined by dax/kmem as PMEM in the first version. And plan to support more memory types in the future versions.

But from your above words, our assumption are wrong here. dax/kmem.c can online HBM and other memory devices already. If so, how do we distinguish between them and how to get the performance character of these devices? We can start with SLIT?

Quoted 129 lines · Ying

Quoted 114 lines · Dan Williams

Quoted 94 lines · Ying

Quoted 92 lines · Dan Williams

Quoted 70 lines · Aneesh Kumar K.V

In the current kernel, memory tiers are defined implicitly via a demotion path relationship between NUMA nodes, which is created during the kernel initialization and updated when a NUMA node is hot-added or hot-removed. The current implementation puts all nodes with CPU into the highest tier, and builds the tier hierarchy tier-by-tier by establishing the per-node demotion targets based on the distances between nodes.

This current memory tier kernel implementation needs to be improved for several important use cases,

The current tier initialization code always initializes each memory-only NUMA node into a lower tier. But a memory-only NUMA node may have a high performance memory device (e.g. a DRAM-backed memory-only node on a virtual machine) that should be put into a higher tier.

The current tier hierarchy always puts CPU nodes into the top tier. But on a system with HBM or GPU devices, the memory-only NUMA nodes mapping these devices should be in the top tier, and DRAM nodes with CPUs are better to be placed into the next lower tier.

With current kernel higher tier node can only be demoted to nodes with shortest distance on the next lower tier as defined by the demotion path, not any other node from any lower tier. This strict, demotion order does not work in all use cases (e.g. some use cases may want to allow cross-socket demotion to another node in the same demotion tier as a fallback when the preferred demotion node is out of space), This demotion order is also inconsistent with the page allocation fallback order when all the nodes in a higher tier are out of space: The page allocation can fall back to any node from any lower tier, whereas the demotion order doesn't allow that.

This patch series address the above by defining memory tiers explicitly.

Linux kernel presents memory devices as NUMA nodes and each memory device is of a specific type. The memory type of a device is represented by its abstract distance. A memory tier corresponds to a range of abstract distance. This allows for classifying memory devices with a specific performance range into a memory tier.

This patch configures the range/chunk size to be 128. The default DRAM abstract distance is 512. We can have 4 memory tiers below the default DRAM abstract distance which cover the range 0 - 127, 127 - 255, 256- 383, 384 - 511. Slower memory devices like persistent memory will have abstract distance below the default DRAM level and hence will be placed in these 4 lower tiers.

A kernel parameter is provided to override the default memory tier.

Link https://lore.kernel.org/linux-mm/CAAPL-u9Wv+nH1VOZTj=9p9S70Y3Qz3+63EkqncRDdHfubsrjfw@mail.gmail.com open here

Link https://lore.kernel.org/linux-mm/[email protected] open here

Signed-off-by Jagdish Gediya <[email protected]>

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 include/linux/memory-tiers.h |  17 ++++++
 mm/Makefile                  |   1 +
 mm/memory-tiers.c            | 102 +++++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+)
 create mode 100644 include/linux/memory-tiers.h
 create mode 100644 mm/memory-tiers.c

include/linux/memory-tiers.h new file +5 -0

new file mode 100644
index 000000000000..8d7884b7a3f0
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MEMORY_TIERS_H
+#define _LINUX_MEMORY_TIERS_H
+
+/*

include/linux/memory-tiers.h line 15

Quoted 10 lines

include/linux/memory-tiers.h new file +10 -0

+ * Each tier cover a abstrace distance chunk size of 128
+ */
+#define MEMTIER_CHUNK_BITS	7
+#define MEMTIER_CHUNK_SIZE	(1 << MEMTIER_CHUNK_BITS)
+/*
+ * For now let's have 4 memory tier below default DRAM tier.
+ */
+#define MEMTIER_ADISTANCE_DRAM	(1 << (MEMTIER_CHUNK_BITS + 2))
+/* leave one tier below this slow pmem */
+#define MEMTIER_ADISTANCE_PMEM	(1 << MEMTIER_CHUNK_BITS)

Why is memory type encoded in these values? There is no reason to believe that PMEM is of a lower performance tier than DRAM. Consider high performance energy backed DRAM that makes it "PMEM", consider CXL attached DRAM over a switch topology and constrained links that makes it a lower performance tier than locally attached DRAM. The names should be associated with tiers that indicate their usage. Something like HOT, GENERAL, and COLD. Where, for example, HOT is low capacity high performance compared to the general purpose pool, and COLD is high capacity low performance intended to offload the general purpose tier.

Quoted 8 lines

Quoted 5 lines

It does not need to be exactly that ontology, but please try to not encode policy meaning behind memory types. There has been explicit effort to avoid that to date because types are fraught for declaring relative performance characteristics, and the relative performance changes based on what memory types are assembled in a given system.

Yes. MEMTIER_ADISTANCE_PMEM is something over simplified. That is only used in this very first version to make it as simple as possible.

I am failing to see the simplicity of using names that convey a performance contract that are invalid depending on the system.

Quoted 3 lines

I think we can come up with something better in the later version. For example, identify the abstract distance of a PMEM device based on HMAT, etc.

Memory tiering has nothing to do with persistence why is PMEM in the name at all?

Quoted 6 lines

Quoted 3 lines

And even in this first version, we should put MEMTIER_ADISTANCE_PMEM in dax/kmem.c. Because it's just for that specific type of memory used now, not for all PMEM.

dax/kmem.c also handles HBM and "soft reserved" memory in general. There is also nothing PMEM specific about the device-dax subsystem.

Ah... I see the issue here. For the systems in our hand, dax/kmem.c is used to online PMEM only. Even the "soft reserved" memory is used for PMEM or simulating PMEM too. So to make the code as simple as possible, we treat all memory devices onlined by dax/kmem as PMEM in the first version. And plan to support more memory types in the future versions.

Quoted 5 lines

But from your above words, our assumption are wrong here. dax/kmem.c can online HBM and other memory devices already. If so, how do we distinguish between them and how to get the performance character of these devices? We can start with SLIT?

We would let low level driver register memory_dev_types for the NUMA nodes that will be mapped to these devices. ie, a papr_scm, ACPI NFIT or CXL can register different memory_dev_type based on device tree, HMAT or CDAT.

Quoted 136 lines · Aneesh Kumar K V

Quoted 134 lines · Ying

Quoted 114 lines · Dan Williams

Quoted 94 lines · Ying

Quoted 92 lines · Dan Williams

Quoted 70 lines · Aneesh Kumar K.V

In the current kernel, memory tiers are defined implicitly via a demotion path relationship between NUMA nodes, which is created during the kernel initialization and updated when a NUMA node is hot-added or hot-removed. The current implementation puts all nodes with CPU into the highest tier, and builds the tier hierarchy tier-by-tier by establishing the per-node demotion targets based on the distances between nodes.

This current memory tier kernel implementation needs to be improved for several important use cases,

The current tier initialization code always initializes each memory-only NUMA node into a lower tier. But a memory-only NUMA node may have a high performance memory device (e.g. a DRAM-backed memory-only node on a virtual machine) that should be put into a higher tier.

The current tier hierarchy always puts CPU nodes into the top tier. But on a system with HBM or GPU devices, the memory-only NUMA nodes mapping these devices should be in the top tier, and DRAM nodes with CPUs are better to be placed into the next lower tier.

With current kernel higher tier node can only be demoted to nodes with shortest distance on the next lower tier as defined by the demotion path, not any other node from any lower tier. This strict, demotion order does not work in all use cases (e.g. some use cases may want to allow cross-socket demotion to another node in the same demotion tier as a fallback when the preferred demotion node is out of space), This demotion order is also inconsistent with the page allocation fallback order when all the nodes in a higher tier are out of space: The page allocation can fall back to any node from any lower tier, whereas the demotion order doesn't allow that.

This patch series address the above by defining memory tiers explicitly.

Linux kernel presents memory devices as NUMA nodes and each memory device is of a specific type. The memory type of a device is represented by its abstract distance. A memory tier corresponds to a range of abstract distance. This allows for classifying memory devices with a specific performance range into a memory tier.

This patch configures the range/chunk size to be 128. The default DRAM abstract distance is 512. We can have 4 memory tiers below the default DRAM abstract distance which cover the range 0 - 127, 127 - 255, 256- 383, 384 - 511. Slower memory devices like persistent memory will have abstract distance below the default DRAM level and hence will be placed in these 4 lower tiers.

A kernel parameter is provided to override the default memory tier.

Link https://lore.kernel.org/linux-mm/CAAPL-u9Wv+nH1VOZTj=9p9S70Y3Qz3+63EkqncRDdHfubsrjfw@mail.gmail.com open here

Link https://lore.kernel.org/linux-mm/[email protected] open here

Signed-off-by Jagdish Gediya <[email protected]>

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 include/linux/memory-tiers.h |  17 ++++++
 mm/Makefile                  |   1 +
 mm/memory-tiers.c            | 102 +++++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+)
 create mode 100644 include/linux/memory-tiers.h
 create mode 100644 mm/memory-tiers.c

include/linux/memory-tiers.h new file +5 -0

new file mode 100644
index 000000000000..8d7884b7a3f0
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MEMORY_TIERS_H
+#define _LINUX_MEMORY_TIERS_H
+
+/*

include/linux/memory-tiers.h line 15

Quoted 10 lines

include/linux/memory-tiers.h new file +10 -0

+ * Each tier cover a abstrace distance chunk size of 128
+ */
+#define MEMTIER_CHUNK_BITS	7
+#define MEMTIER_CHUNK_SIZE	(1 << MEMTIER_CHUNK_BITS)
+/*
+ * For now let's have 4 memory tier below default DRAM tier.
+ */
+#define MEMTIER_ADISTANCE_DRAM	(1 << (MEMTIER_CHUNK_BITS + 2))
+/* leave one tier below this slow pmem */
+#define MEMTIER_ADISTANCE_PMEM	(1 << MEMTIER_CHUNK_BITS)

Why is memory type encoded in these values? There is no reason to believe that PMEM is of a lower performance tier than DRAM. Consider high performance energy backed DRAM that makes it "PMEM", consider CXL attached DRAM over a switch topology and constrained links that makes it a lower performance tier than locally attached DRAM. The names should be associated with tiers that indicate their usage. Something like HOT, GENERAL, and COLD. Where, for example, HOT is low capacity high performance compared to the general purpose pool, and COLD is high capacity low performance intended to offload the general purpose tier.

Quoted 8 lines

Quoted 5 lines

It does not need to be exactly that ontology, but please try to not encode policy meaning behind memory types. There has been explicit effort to avoid that to date because types are fraught for declaring relative performance characteristics, and the relative performance changes based on what memory types are assembled in a given system.

Yes. MEMTIER_ADISTANCE_PMEM is something over simplified. That is only used in this very first version to make it as simple as possible.

I am failing to see the simplicity of using names that convey a performance contract that are invalid depending on the system.

Quoted 3 lines

I think we can come up with something better in the later version. For example, identify the abstract distance of a PMEM device based on HMAT, etc.

Memory tiering has nothing to do with persistence why is PMEM in the name at all?

Quoted 6 lines

Quoted 3 lines

And even in this first version, we should put MEMTIER_ADISTANCE_PMEM in dax/kmem.c. Because it's just for that specific type of memory used now, not for all PMEM.

dax/kmem.c also handles HBM and "soft reserved" memory in general. There is also nothing PMEM specific about the device-dax subsystem.

Ah... I see the issue here. For the systems in our hand, dax/kmem.c is used to online PMEM only. Even the "soft reserved" memory is used for PMEM or simulating PMEM too. So to make the code as simple as possible, we treat all memory devices onlined by dax/kmem as PMEM in the first version. And plan to support more memory types in the future versions.

But from your above words, our assumption are wrong here. dax/kmem.c can online HBM and other memory devices already. If so, how do we distinguish between them and how to get the performance character of these devices? We can start with SLIT?

Quoted 3 lines

We would let low level driver register memory_dev_types for the NUMA nodes that will be mapped to these devices. ie, a papr_scm, ACPI NFIT or CXL can register different memory_dev_type based on device tree, HMAT or CDAT.

I didn't find ACPI NFIT can provide any performance information, just whether it's non-volatile. HMAT or CDAT should help here, but it's not available always. For now, what we have is just SLIT at least for quite some machines.

I prefer to create memory_dev_type in high level driver like dax/kmem. And it may query low level driver like SLIT, HMAT, CDAT, etc for more information based on availability etc.

Best Regards,
Huang, Ying

Quoted 138 lines · Ying

Quoted 136 lines · Aneesh Kumar K V

Quoted 134 lines · Ying

Quoted 114 lines · Dan Williams

Quoted 94 lines · Ying

Quoted 92 lines · Dan Williams

Quoted 70 lines · Aneesh Kumar K.V

In the current kernel, memory tiers are defined implicitly via a demotion path relationship between NUMA nodes, which is created during the kernel initialization and updated when a NUMA node is hot-added or hot-removed. The current implementation puts all nodes with CPU into the highest tier, and builds the tier hierarchy tier-by-tier by establishing the per-node demotion targets based on the distances between nodes.

This current memory tier kernel implementation needs to be improved for several important use cases,

The current tier initialization code always initializes each memory-only NUMA node into a lower tier. But a memory-only NUMA node may have a high performance memory device (e.g. a DRAM-backed memory-only node on a virtual machine) that should be put into a higher tier.

The current tier hierarchy always puts CPU nodes into the top tier. But on a system with HBM or GPU devices, the memory-only NUMA nodes mapping these devices should be in the top tier, and DRAM nodes with CPUs are better to be placed into the next lower tier.

With current kernel higher tier node can only be demoted to nodes with shortest distance on the next lower tier as defined by the demotion path, not any other node from any lower tier. This strict, demotion order does not work in all use cases (e.g. some use cases may want to allow cross-socket demotion to another node in the same demotion tier as a fallback when the preferred demotion node is out of space), This demotion order is also inconsistent with the page allocation fallback order when all the nodes in a higher tier are out of space: The page allocation can fall back to any node from any lower tier, whereas the demotion order doesn't allow that.

This patch series address the above by defining memory tiers explicitly.

Linux kernel presents memory devices as NUMA nodes and each memory device is of a specific type. The memory type of a device is represented by its abstract distance. A memory tier corresponds to a range of abstract distance. This allows for classifying memory devices with a specific performance range into a memory tier.

This patch configures the range/chunk size to be 128. The default DRAM abstract distance is 512. We can have 4 memory tiers below the default DRAM abstract distance which cover the range 0 - 127, 127 - 255, 256- 383, 384 - 511. Slower memory devices like persistent memory will have abstract distance below the default DRAM level and hence will be placed in these 4 lower tiers.

A kernel parameter is provided to override the default memory tier.

Link https://lore.kernel.org/linux-mm/CAAPL-u9Wv+nH1VOZTj=9p9S70Y3Qz3+63EkqncRDdHfubsrjfw@mail.gmail.com open here

Link https://lore.kernel.org/linux-mm/[email protected] open here

Signed-off-by Jagdish Gediya <[email protected]>

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 include/linux/memory-tiers.h |  17 ++++++
 mm/Makefile                  |   1 +
 mm/memory-tiers.c            | 102 +++++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+)
 create mode 100644 include/linux/memory-tiers.h
 create mode 100644 mm/memory-tiers.c

include/linux/memory-tiers.h new file +5 -0

new file mode 100644
index 000000000000..8d7884b7a3f0
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MEMORY_TIERS_H
+#define _LINUX_MEMORY_TIERS_H
+
+/*

include/linux/memory-tiers.h line 15

Quoted 10 lines

include/linux/memory-tiers.h new file +10 -0

+ * Each tier cover a abstrace distance chunk size of 128
+ */
+#define MEMTIER_CHUNK_BITS	7
+#define MEMTIER_CHUNK_SIZE	(1 << MEMTIER_CHUNK_BITS)
+/*
+ * For now let's have 4 memory tier below default DRAM tier.
+ */
+#define MEMTIER_ADISTANCE_DRAM	(1 << (MEMTIER_CHUNK_BITS + 2))
+/* leave one tier below this slow pmem */
+#define MEMTIER_ADISTANCE_PMEM	(1 << MEMTIER_CHUNK_BITS)

Why is memory type encoded in these values? There is no reason to believe that PMEM is of a lower performance tier than DRAM. Consider high performance energy backed DRAM that makes it "PMEM", consider CXL attached DRAM over a switch topology and constrained links that makes it a lower performance tier than locally attached DRAM. The names should be associated with tiers that indicate their usage. Something like HOT, GENERAL, and COLD. Where, for example, HOT is low capacity high performance compared to the general purpose pool, and COLD is high capacity low performance intended to offload the general purpose tier.

Quoted 8 lines

Quoted 5 lines

It does not need to be exactly that ontology, but please try to not encode policy meaning behind memory types. There has been explicit effort to avoid that to date because types are fraught for declaring relative performance characteristics, and the relative performance changes based on what memory types are assembled in a given system.

Yes. MEMTIER_ADISTANCE_PMEM is something over simplified. That is only used in this very first version to make it as simple as possible.

I am failing to see the simplicity of using names that convey a performance contract that are invalid depending on the system.

Quoted 3 lines

I think we can come up with something better in the later version. For example, identify the abstract distance of a PMEM device based on HMAT, etc.

Memory tiering has nothing to do with persistence why is PMEM in the name at all?

Quoted 6 lines

Quoted 3 lines

And even in this first version, we should put MEMTIER_ADISTANCE_PMEM in dax/kmem.c. Because it's just for that specific type of memory used now, not for all PMEM.

dax/kmem.c also handles HBM and "soft reserved" memory in general. There is also nothing PMEM specific about the device-dax subsystem.

Ah... I see the issue here. For the systems in our hand, dax/kmem.c is used to online PMEM only. Even the "soft reserved" memory is used for PMEM or simulating PMEM too. So to make the code as simple as possible, we treat all memory devices onlined by dax/kmem as PMEM in the first version. And plan to support more memory types in the future versions.

But from your above words, our assumption are wrong here. dax/kmem.c can online HBM and other memory devices already. If so, how do we distinguish between them and how to get the performance character of these devices? We can start with SLIT?

Quoted 9 lines

Quoted 3 lines

We would let low level driver register memory_dev_types for the NUMA nodes that will be mapped to these devices. ie, a papr_scm, ACPI NFIT or CXL can register different memory_dev_type based on device tree, HMAT or CDAT.

I didn't find ACPI NFIT can provide any performance information, just whether it's non-volatile. HMAT or CDAT should help here, but it's not available always. For now, what we have is just SLIT at least for quite some machines.

The lower level driver that is creating the nvdimm regions can assign a memory type to the numa node which it associates with the region. For now, drivers like papr_scm do that on ppc64. When it associates a numa node to nvdimm regions, it can query every detail available (device tree in case of papr_scm, can be HMAT/SLIT or CDAT) to associate the NUMA node to a memory type.

Quoted 6 lines

I prefer to create memory_dev_type in high level driver like dax/kmem. And it may query low level driver like SLIT, HMAT, CDAT, etc for more information based on availability etc.

Best Regards,
Huang, Ying

By default, all nodes are assigned to the default memory tier which is the memory tier designated for nodes with DRAM

Set dax kmem device node's tier to slower memory tier by assigning abstract distance to MEMTIER_ADISTANCE_PMEM. PMEM tier appears below the default memory tier in demotion order.

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 drivers/dax/kmem.c           |  9 +++++++++
 include/linux/memory-tiers.h | 19 ++++++++++++++++++-
 mm/memory-tiers.c            | 28 ++++++++++++++++------------
 3 files changed, 43 insertions(+), 13 deletions(-)

drivers/dax/kmem.c +1 -0

index a37622060fff..6b0d5de9a3e9 100644
@@ -11,6 +11,7 @@
 #include <linux/fs.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
+#include <linux/memory-tiers.h>
 #include "dax-private.h"
 #include "bus.h"
 

drivers/dax/kmem.c +5 -0

+	.adistance = MEMTIER_ADISTANCE_PMEM,
+	.tier_sibiling = LIST_HEAD_INIT(default_pmem_type.tier_sibiling),
+	.nodes  = NODE_MASK_NONE,
+};
+
 static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 {
 	struct device *dev = &dev_dax->dev;

drivers/dax/kmem.c +0 -0

 	for (i = 0; i < dev_dax->nr_range; i++) {
 		struct range range;
 

include/linux/memory-tiers.h +18 -1

index 976f43a5e3be..4f4baf0bf430 100644
@@ -2,6 +2,8 @@
 #ifndef _LINUX_MEMORY_TIERS_H
 #define _LINUX_MEMORY_TIERS_H
 
+#include <linux/types.h>
+#include <linux/nodemask.h>
 /*
  * Each tier cover a abstrace distance chunk size of 128
  */

@@ -15,12 +17,27 @@
 #define MEMTIER_ADISTANCE_PMEM	(1 << MEMTIER_CHUNK_BITS)
 #define MEMTIER_HOTPLUG_PRIO	100
 
+struct memory_tier;
+struct memory_dev_type {
+	/* list of memory types that are are part of same tier as this type */
+	struct list_head tier_sibiling;
+	/* abstract distance for this specific memory type */
+	int adistance;
+	/* Nodes of same abstract distance */
+	nodemask_t nodes;
+	struct memory_tier *memtier;
+};
+
 #ifdef CONFIG_NUMA
-#include <linux/types.h>
 extern bool numa_demotion_enabled;
+struct memory_dev_type *init_node_memory_type(int node, struct memory_dev_type *default_type);
 
 #else
 
 #define numa_demotion_enabled	false
+static inline struct memory_dev_type *init_node_memory_type(int node, struct memory_dev_type *default_type)
+{
+	return ERR_PTR(-EINVAL);
+}
 #endif	/* CONFIG_NUMA */
 #endif  /* _LINUX_MEMORY_TIERS_H */

mm/memory-tiers.c +16 -12

index c9854a394d9b..109be75fa554 100644
@@ -1,6 +1,4 @@
 // SPDX-License-Identifier: GPL-2.0
-#include <linux/types.h>
-#include <linux/nodemask.h>
 #include <linux/slab.h>
 #include <linux/lockdep.h>
 #include <linux/memory.h>

@@ -19,16 +17,6 @@ struct memory_tier {
 	int adistance_start;
 };
 
-struct memory_dev_type {
-	/* list of memory types that are are part of same tier as this type */
-	struct list_head tier_sibiling;
-	/* abstract distance for this specific memory type */
-	int adistance;
-	/* Nodes of same abstract distance */
-	nodemask_t nodes;
-	struct memory_tier *memtier;
-};
-
 static DEFINE_MUTEX(memory_tier_lock);
 static LIST_HEAD(memory_tiers);
 struct memory_dev_type *node_memory_types[MAX_NUMNODES];

@@ -141,6 +129,22 @@ static void clear_node_memory_tier(int node)
 	mutex_unlock(&memory_tier_lock);
 }
 
+struct memory_dev_type *init_node_memory_type(int node, struct memory_dev_type *default_type)
+{
+	struct memory_dev_type *mem_type;
+
+	mutex_lock(&memory_tier_lock);
+	if (node_memory_types[node]) {
+		mem_type = node_memory_types[node];
+	} else {
+		node_memory_types[node] = default_type;
+		node_set(node, default_type->nodes);
+		mem_type = default_type;
+	}
+	mutex_unlock(&memory_tier_lock);
+	return mem_type;
+}
+
 static int __meminit memtier_hotplug_callback(struct notifier_block *self,
 					      unsigned long action, void *_arg)
 {

Quoted 26 lines · Aneesh Kumar K.V

By default, all nodes are assigned to the default memory tier which is the memory tier designated for nodes with DRAM

Set dax kmem device node's tier to slower memory tier by assigning abstract distance to MEMTIER_ADISTANCE_PMEM. PMEM tier appears below the default memory tier in demotion order.

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 drivers/dax/kmem.c           |  9 +++++++++
 include/linux/memory-tiers.h | 19 ++++++++++++++++++-
 mm/memory-tiers.c            | 28 ++++++++++++++++------------
 3 files changed, 43 insertions(+), 13 deletions(-)

drivers/dax/kmem.c +1 -0

index a37622060fff..6b0d5de9a3e9 100644
@@ -11,6 +11,7 @@
 #include <linux/fs.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
+#include <linux/memory-tiers.h>
 #include "dax-private.h"
 #include "bus.h"
 

drivers/dax/kmem.c struct dax_kmem_data { · line 45

Quoted 5 lines

drivers/dax/kmem.c +1 -0

@@ -41,6 +42,12 @@ struct dax_kmem_data {
 	struct resource *res[];
 };
 
+static struct memory_dev_type default_pmem_type  = {

Why is this named as default_pmem_type? We will not change the memory type of a node usually.

Quoted 9 lines

drivers/dax/kmem.c +5 -0

+	.adistance = MEMTIER_ADISTANCE_PMEM,
+	.tier_sibiling = LIST_HEAD_INIT(default_pmem_type.tier_sibiling),
+	.nodes  = NODE_MASK_NONE,
+};
+
 static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 {
 	struct device *dev = &dev_dax->dev;

drivers/dax/kmem.c static int dev_dax_kmem_probe(struct dev_dax *dev_dax) · line 73

Quoted 5 lines

drivers/dax/kmem.c +2 -0

@@ -62,6 +69,8 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 		return -EINVAL;
 	}
 
+	init_node_memory_type(numa_node, &default_pmem_type);
+

The memory hot-add below may fail. So the error handling needs to be added.

And, it appears that the memory type and memory tier of a node may be fully initialized here before NUMA hot-adding started. So I suggest to set node_memory_types[] here only. And set memory_dev_type->nodes in node hot-add callback. I think there is the proper place to complete the initialization.

And, in theory dax/kmem.c can be unloaded. So we need to clear node_memory_types[] for nodes somewhere.

Quoted 32 lines · Ying

Quoted 30 lines · Aneesh Kumar K.V

By default, all nodes are assigned to the default memory tier which is the memory tier designated for nodes with DRAM

Set dax kmem device node's tier to slower memory tier by assigning abstract distance to MEMTIER_ADISTANCE_PMEM. PMEM tier appears below the default memory tier in demotion order.

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 drivers/dax/kmem.c           |  9 +++++++++
 include/linux/memory-tiers.h | 19 ++++++++++++++++++-
 mm/memory-tiers.c            | 28 ++++++++++++++++------------
 3 files changed, 43 insertions(+), 13 deletions(-)

drivers/dax/kmem.c +1 -0

index a37622060fff..6b0d5de9a3e9 100644
@@ -11,6 +11,7 @@
 #include <linux/fs.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
+#include <linux/memory-tiers.h>
 #include "dax-private.h"
 #include "bus.h"
 

@@ -41,6 +42,12 @@ struct dax_kmem_data {
 	struct resource *res[];
 };
 

Quoted 5 lines

drivers/dax/kmem.c struct dax_kmem_data { · line 45

Quoted 1 line

drivers/dax/kmem.c +1 -0

+static struct memory_dev_type default_pmem_type  = {

Why is this named as default_pmem_type? We will not change the memory type of a node usually.

Any other suggestion? pmem_dev_type?

Quoted 25 lines

Quoted 10 lines

drivers/dax/kmem.c +5 -0

+	.adistance = MEMTIER_ADISTANCE_PMEM,
+	.tier_sibiling = LIST_HEAD_INIT(default_pmem_type.tier_sibiling),
+	.nodes  = NODE_MASK_NONE,
+};
+
 static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 {
 	struct device *dev = &dev_dax->dev;

drivers/dax/kmem.c static int dev_dax_kmem_probe(struct dev_dax *dev_dax) · line 73

Quoted 5 lines

drivers/dax/kmem.c +2 -0

@@ -62,6 +69,8 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 		return -EINVAL;
 	}
 
+	init_node_memory_type(numa_node, &default_pmem_type);
+

The memory hot-add below may fail. So the error handling needs to be added.

And, it appears that the memory type and memory tier of a node may be fully initialized here before NUMA hot-adding started. So I suggest to set node_memory_types[] here only. And set memory_dev_type->nodes in node hot-add callback. I think there is the proper place to complete the initialization.

Quoted 3 lines

And, in theory dax/kmem.c can be unloaded. So we need to clear node_memory_types[] for nodes somewhere.

I guess by module exit we can be sure that all the memory managed by dax/kmem is hotplugged out. How about something like below?

drivers/dax/kmem.c +1 -0

index 6b0d5de9a3e9..eb4e158012a9 100644
@@ -248,6 +248,7 @@ static void __exit dax_kmem_exit(void)
 	dax_driver_unregister(&device_dax_kmem_driver);
 	if (!any_hotremove_failed)
 		kfree_const(kmem_name);
+	unregister_memory_type(&default_pmem_type);
 }
 
 MODULE_AUTHOR("Intel Corporation");

include/linux/memory-tiers.h +5 -0

index fc6b7a14da51..8355baf5b8b4 100644
@@ -31,6 +31,7 @@ struct memory_dev_type {
 #ifdef CONFIG_NUMA
 extern bool numa_demotion_enabled;
 void init_node_memory_type(int node, struct memory_dev_type *default_type);
+void unregister_memory_type(struct memory_dev_type *memtype);
 #ifdef CONFIG_MIGRATION
 int next_demotion_node(int node);
 void node_get_allowed_targets(pg_data_t *pgdat, nodemask_t *targets);

@@ -57,6 +58,10 @@ static inline bool node_is_toptier(int node)
 #define numa_demotion_enabled	false
 static inline void init_node_memory_type(int node, struct memory_dev_type *default_type)
 {
+}
+
+static inline void unregister_memory_type(struct memory_dev_type *memtype)
+{
 
 }
 

mm/memory-tiers.c +22 -0

index 064e0f932795..4d29ebd4c4f3 100644
@@ -500,6 +500,28 @@ void init_node_memory_type(int node, struct memory_dev_type *default_type)
 	mutex_unlock(&memory_tier_lock);
 }
 
+void unregister_memory_type(struct memory_dev_type *memtype)
+{
+	int node;
+	struct memory_tier *memtier = memtype->memtier;
+
+	mutex_lock(&memory_tier_lock);
+	for(node = 0; node < MAX_NUMNODES; node++) {
+		if (node_memory_types[node] == memtype) {
+			if (!nodes_empty(memtype->nodes))
+				WARN_ON(1);
+			node_memory_types[node] = NULL;
+		}
+	}
+
+	list_del(&memtype->tier_sibiling);
+	memtype->memtier = NULL;
+	if (list_empty(&memtier->memory_types))
+		destroy_memory_tier(memtier);
+
+	mutex_unlock(&memory_tier_lock);
+}
+
 void update_node_adistance(int node, struct memory_dev_type *memtype)
 {
 	pg_data_t *pgdat;

Quoted 34 lines · Aneesh Kumar K.V

Quoted 32 lines · Ying

Quoted 30 lines · Aneesh Kumar K.V

By default, all nodes are assigned to the default memory tier which is the memory tier designated for nodes with DRAM

Set dax kmem device node's tier to slower memory tier by assigning abstract distance to MEMTIER_ADISTANCE_PMEM. PMEM tier appears below the default memory tier in demotion order.

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 drivers/dax/kmem.c           |  9 +++++++++
 include/linux/memory-tiers.h | 19 ++++++++++++++++++-
 mm/memory-tiers.c            | 28 ++++++++++++++++------------
 3 files changed, 43 insertions(+), 13 deletions(-)

drivers/dax/kmem.c +1 -0

index a37622060fff..6b0d5de9a3e9 100644
@@ -11,6 +11,7 @@
 #include <linux/fs.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
+#include <linux/memory-tiers.h>
 #include "dax-private.h"
 #include "bus.h"
 

@@ -41,6 +42,12 @@ struct dax_kmem_data {
 	struct resource *res[];
 };
 

Quoted 7 lines

Quoted 5 lines

drivers/dax/kmem.c struct dax_kmem_data { · line 45

Quoted 1 line

drivers/dax/kmem.c +1 -0

+static struct memory_dev_type default_pmem_type  = {

Why is this named as default_pmem_type? We will not change the memory type of a node usually.

Any other suggestion? pmem_dev_type?

Or dax_pmem_type?

DAX is used to enumerate the memory device.

Quoted 29 lines

Quoted 28 lines

Quoted 10 lines

drivers/dax/kmem.c +5 -0

+	.adistance = MEMTIER_ADISTANCE_PMEM,
+	.tier_sibiling = LIST_HEAD_INIT(default_pmem_type.tier_sibiling),
+	.nodes  = NODE_MASK_NONE,
+};
+
 static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 {
 	struct device *dev = &dev_dax->dev;

drivers/dax/kmem.c static int dev_dax_kmem_probe(struct dev_dax *dev_dax) · line 73

Quoted 5 lines

drivers/dax/kmem.c +2 -0

@@ -62,6 +69,8 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 		return -EINVAL;
 	}
 
+	init_node_memory_type(numa_node, &default_pmem_type);
+

The memory hot-add below may fail. So the error handling needs to be added.

And, it appears that the memory type and memory tier of a node may be fully initialized here before NUMA hot-adding started. So I suggest to set node_memory_types[] here only. And set memory_dev_type->nodes in node hot-add callback. I think there is the proper place to complete the initialization.

And, in theory dax/kmem.c can be unloaded. So we need to clear node_memory_types[] for nodes somewhere.

Quoted 2 lines

I guess by module exit we can be sure that all the memory managed by dax/kmem is hotplugged out. How about something like below?

Because we set node_memorty_types[] in dev_dax_kmem_probe(), it's natural to clear it in dev_dax_kmem_remove().

Quoted 77 lines · Ying

Quoted 34 lines · Aneesh Kumar K.V

Quoted 32 lines · Ying

Quoted 30 lines · Aneesh Kumar K.V

By default, all nodes are assigned to the default memory tier which is the memory tier designated for nodes with DRAM

Set dax kmem device node's tier to slower memory tier by assigning abstract distance to MEMTIER_ADISTANCE_PMEM. PMEM tier appears below the default memory tier in demotion order.

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 drivers/dax/kmem.c           |  9 +++++++++
 include/linux/memory-tiers.h | 19 ++++++++++++++++++-
 mm/memory-tiers.c            | 28 ++++++++++++++++------------
 3 files changed, 43 insertions(+), 13 deletions(-)

drivers/dax/kmem.c +1 -0

index a37622060fff..6b0d5de9a3e9 100644
@@ -11,6 +11,7 @@
 #include <linux/fs.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
+#include <linux/memory-tiers.h>
 #include "dax-private.h"
 #include "bus.h"
 

@@ -41,6 +42,12 @@ struct dax_kmem_data {
 	struct resource *res[];
 };
 

Quoted 7 lines

Quoted 5 lines

drivers/dax/kmem.c struct dax_kmem_data { · line 45

Quoted 1 line

drivers/dax/kmem.c +1 -0

+static struct memory_dev_type default_pmem_type  = {

Why is this named as default_pmem_type? We will not change the memory type of a node usually.

Any other suggestion? pmem_dev_type?

Or dax_pmem_type?

DAX is used to enumerate the memory device.

Quoted 29 lines

Quoted 28 lines

Quoted 10 lines

drivers/dax/kmem.c +5 -0

+	.adistance = MEMTIER_ADISTANCE_PMEM,
+	.tier_sibiling = LIST_HEAD_INIT(default_pmem_type.tier_sibiling),
+	.nodes  = NODE_MASK_NONE,
+};
+
 static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 {
 	struct device *dev = &dev_dax->dev;

drivers/dax/kmem.c static int dev_dax_kmem_probe(struct dev_dax *dev_dax) · line 73

Quoted 5 lines

drivers/dax/kmem.c +2 -0

@@ -62,6 +69,8 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 		return -EINVAL;
 	}
 
+	init_node_memory_type(numa_node, &default_pmem_type);
+

The memory hot-add below may fail. So the error handling needs to be added.

And, it appears that the memory type and memory tier of a node may be fully initialized here before NUMA hot-adding started. So I suggest to set node_memory_types[] here only. And set memory_dev_type->nodes in node hot-add callback. I think there is the proper place to complete the initialization.

And, in theory dax/kmem.c can be unloaded. So we need to clear node_memory_types[] for nodes somewhere.

Quoted 6 lines

Quoted 2 lines

I guess by module exit we can be sure that all the memory managed by dax/kmem is hotplugged out. How about something like below?

Because we set node_memorty_types[] in dev_dax_kmem_probe(), it's natural to clear it in dev_dax_kmem_remove().

Most of required reset/clear is done as part of memory hotunplug. So if we did manage to successfully unplug the memory, everything except node_memory_types[node] should be reset. That makes the clear_node_memory_type the below.

void clear_node_memory_type(int node, struct memory_dev_type *memtype) {

	mutex_lock(&memory_tier_lock);
	/*
	 * memory unplug did clear the node from the memtype and
	 * dax/kem did initialize this node's memory type.
	 */
	if (!node_isset(node, memtype->nodes) && node_memory_types[node]  == memtype){
		node_memory_types[node] = NULL;
	}
	mutex_unlock(&memory_tier_lock);
}

With the module unload, it is kind of force removing the usage of the specific memtype. Considering module unload will remove the usage of specific memtype from other parts of the kernel and we already do all the required reset in memory hot unplug, do we need to do the clear_node_memory_type above?

Quoted 104 lines · Aneesh Kumar K V

Quoted 77 lines · Ying

Quoted 34 lines · Aneesh Kumar K.V

Quoted 32 lines · Ying

Quoted 30 lines · Aneesh Kumar K.V

By default, all nodes are assigned to the default memory tier which is the memory tier designated for nodes with DRAM

Set dax kmem device node's tier to slower memory tier by assigning abstract distance to MEMTIER_ADISTANCE_PMEM. PMEM tier appears below the default memory tier in demotion order.

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 drivers/dax/kmem.c           |  9 +++++++++
 include/linux/memory-tiers.h | 19 ++++++++++++++++++-
 mm/memory-tiers.c            | 28 ++++++++++++++++------------
 3 files changed, 43 insertions(+), 13 deletions(-)

drivers/dax/kmem.c +1 -0

index a37622060fff..6b0d5de9a3e9 100644
@@ -11,6 +11,7 @@
 #include <linux/fs.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
+#include <linux/memory-tiers.h>
 #include "dax-private.h"
 #include "bus.h"
 

@@ -41,6 +42,12 @@ struct dax_kmem_data {
 	struct resource *res[];
 };
 

Quoted 7 lines

Quoted 5 lines

drivers/dax/kmem.c struct dax_kmem_data { · line 45

Quoted 1 line

drivers/dax/kmem.c +1 -0

+static struct memory_dev_type default_pmem_type  = {

Why is this named as default_pmem_type? We will not change the memory type of a node usually.

Any other suggestion? pmem_dev_type?

Or dax_pmem_type?

DAX is used to enumerate the memory device.

Quoted 29 lines

Quoted 28 lines

Quoted 10 lines

drivers/dax/kmem.c +5 -0

+	.adistance = MEMTIER_ADISTANCE_PMEM,
+	.tier_sibiling = LIST_HEAD_INIT(default_pmem_type.tier_sibiling),
+	.nodes  = NODE_MASK_NONE,
+};
+
 static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 {
 	struct device *dev = &dev_dax->dev;

drivers/dax/kmem.c static int dev_dax_kmem_probe(struct dev_dax *dev_dax) · line 73

Quoted 5 lines

drivers/dax/kmem.c +2 -0

@@ -62,6 +69,8 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 		return -EINVAL;
 	}
 
+	init_node_memory_type(numa_node, &default_pmem_type);
+

The memory hot-add below may fail. So the error handling needs to be added.

And, it appears that the memory type and memory tier of a node may be fully initialized here before NUMA hot-adding started. So I suggest to set node_memory_types[] here only. And set memory_dev_type->nodes in node hot-add callback. I think there is the proper place to complete the initialization.

And, in theory dax/kmem.c can be unloaded. So we need to clear node_memory_types[] for nodes somewhere.

Quoted 6 lines

Quoted 2 lines

I guess by module exit we can be sure that all the memory managed by dax/kmem is hotplugged out. How about something like below?

Because we set node_memorty_types[] in dev_dax_kmem_probe(), it's natural to clear it in dev_dax_kmem_remove().

Most of required reset/clear is done as part of memory hotunplug. So if we did manage to successfully unplug the memory, everything except node_memory_types[node] should be reset. That makes the clear_node_memory_type the below.

void clear_node_memory_type(int node, struct memory_dev_type *memtype) {

	mutex_lock(&memory_tier_lock);
	/*
	 * memory unplug did clear the node from the memtype and
	 * dax/kem did initialize this node's memory type.
	 */
	if (!node_isset(node, memtype->nodes) && node_memory_types[node]  == memtype){
		node_memory_types[node] = NULL;
	}
	mutex_unlock(&memory_tier_lock);
}

Quoted 4 lines

With the module unload, it is kind of force removing the usage of the specific memtype. Considering module unload will remove the usage of specific memtype from other parts of the kernel and we already do all the required reset in memory hot unplug, do we need to do the clear_node_memory_type above?

Per my understanding, we need to call clear_node_memory_type() in dev_dax_kmem_remove(). After that, we have nothing to do in dax_kmem_exit().

Quoted 111 lines · Ying

Quoted 108 lines · Aneesh Kumar K V

Quoted 77 lines · Ying

Quoted 34 lines · Aneesh Kumar K.V

Quoted 32 lines · Ying

Quoted 30 lines · Aneesh Kumar K.V

By default, all nodes are assigned to the default memory tier which is the memory tier designated for nodes with DRAM

Set dax kmem device node's tier to slower memory tier by assigning abstract distance to MEMTIER_ADISTANCE_PMEM. PMEM tier appears below the default memory tier in demotion order.

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 drivers/dax/kmem.c           |  9 +++++++++
 include/linux/memory-tiers.h | 19 ++++++++++++++++++-
 mm/memory-tiers.c            | 28 ++++++++++++++++------------
 3 files changed, 43 insertions(+), 13 deletions(-)

drivers/dax/kmem.c +1 -0

index a37622060fff..6b0d5de9a3e9 100644
@@ -11,6 +11,7 @@
 #include <linux/fs.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
+#include <linux/memory-tiers.h>
 #include "dax-private.h"
 #include "bus.h"
 

@@ -41,6 +42,12 @@ struct dax_kmem_data {
 	struct resource *res[];
 };
 

Quoted 7 lines

Quoted 5 lines

drivers/dax/kmem.c struct dax_kmem_data { · line 45

Quoted 1 line

drivers/dax/kmem.c +1 -0

+static struct memory_dev_type default_pmem_type  = {

Why is this named as default_pmem_type? We will not change the memory type of a node usually.

Any other suggestion? pmem_dev_type?

Or dax_pmem_type?

DAX is used to enumerate the memory device.

Quoted 29 lines

Quoted 28 lines

Quoted 10 lines

drivers/dax/kmem.c +5 -0

+	.adistance = MEMTIER_ADISTANCE_PMEM,
+	.tier_sibiling = LIST_HEAD_INIT(default_pmem_type.tier_sibiling),
+	.nodes  = NODE_MASK_NONE,
+};
+
 static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 {
 	struct device *dev = &dev_dax->dev;

drivers/dax/kmem.c static int dev_dax_kmem_probe(struct dev_dax *dev_dax) · line 73

Quoted 5 lines

drivers/dax/kmem.c +2 -0

@@ -62,6 +69,8 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 		return -EINVAL;
 	}
 
+	init_node_memory_type(numa_node, &default_pmem_type);
+

The memory hot-add below may fail. So the error handling needs to be added.

And, it appears that the memory type and memory tier of a node may be fully initialized here before NUMA hot-adding started. So I suggest to set node_memory_types[] here only. And set memory_dev_type->nodes in node hot-add callback. I think there is the proper place to complete the initialization.

And, in theory dax/kmem.c can be unloaded. So we need to clear node_memory_types[] for nodes somewhere.

Quoted 6 lines

Quoted 2 lines

I guess by module exit we can be sure that all the memory managed by dax/kmem is hotplugged out. How about something like below?

Because we set node_memorty_types[] in dev_dax_kmem_probe(), it's natural to clear it in dev_dax_kmem_remove().

Most of required reset/clear is done as part of memory hotunplug. So if we did manage to successfully unplug the memory, everything except node_memory_types[node] should be reset. That makes the clear_node_memory_type the below.

void clear_node_memory_type(int node, struct memory_dev_type *memtype) {

	mutex_lock(&memory_tier_lock);
	/*
	 * memory unplug did clear the node from the memtype and
	 * dax/kem did initialize this node's memory type.
	 */
	if (!node_isset(node, memtype->nodes) && node_memory_types[node]  == memtype){
		node_memory_types[node] = NULL;
	}
	mutex_unlock(&memory_tier_lock);
}

With the module unload, it is kind of force removing the usage of the specific memtype. Considering module unload will remove the usage of specific memtype from other parts of the kernel and we already do all the required reset in memory hot unplug, do we need to do the clear_node_memory_type above?

Quoted 4 lines

Per my understanding, we need to call clear_node_memory_type() in dev_dax_kmem_remove(). After that, we have nothing to do in dax_kmem_exit().

Ok, I guess you are suggesting to do the clear_node_memory_type even if we fail the memory remove.

Should we also rebuild demotion order? On a successful memory remove we do rebuild demotion order. This is what i ended up with.

modified drivers/dax/kmem.c

(quoted diff) +7 -0

@@ -171,6 +171,7 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
 static void dev_dax_kmem_remove(struct dev_dax *dev_dax)
 {
 	int i, success = 0;
+	int node = dev_dax->target_node;
 	struct device *dev = &dev_dax->dev;
 	struct dax_kmem_data *data = dev_get_drvdata(dev);
 

@@ -208,6 +209,12 @@ static void dev_dax_kmem_remove(struct dev_dax *dev_dax)
 		kfree(data);
 		dev_set_drvdata(dev, NULL);
 	}
+	/*
+	 * Clear the memtype association, even if the memory
+	 * remove failed.
+	 */
+	clear_node_memory_type(node, dax_pmem_type);
+
 }
 #else
 static void dev_dax_kmem_remove(struct dev_dax *dev_dax)

modified include/linux/memory-tiers.h

include/linux/memory-tiers.h +5 -0

@@ -31,6 +31,7 @@ struct memory_dev_type {
 #ifdef CONFIG_NUMA
 extern bool numa_demotion_enabled;
 void init_node_memory_type(int node, struct memory_dev_type *default_type);
+void clear_node_memory_type(int node, struct memory_dev_type *memtype);
 #ifdef CONFIG_MIGRATION
 int next_demotion_node(int node);
 void node_get_allowed_targets(pg_data_t *pgdat, nodemask_t *targets);

@@ -57,6 +58,10 @@ static inline bool node_is_toptier(int node)
 #define numa_demotion_enabled	false
 static inline void init_node_memory_type(int node, struct memory_dev_type *default_type)
 {
+}
+
+static inline void unregister_memory_type(struct memory_dev_type *memtype)
+{
 
 }
 

modified mm/memory-tiers.c

(quoted diff) +30 -0

@@ -501,6 +501,36 @@ void init_node_memory_type(int node, struct memory_dev_type *default_type)
 }
 EXPORT_SYMBOL_GPL(init_node_memory_type);
 
+void clear_node_memory_type(int node, struct memory_dev_type *memtype)
+{
+	struct memory_tier *memtier;
+
+	mutex_lock(&memory_tier_lock);
+	/*
+	 * Even if we fail to unplug memory, clear the association of
+	 * this node to this specific memory type.
+	 */
+	if (node_memory_types[node] == memtype) {
+
+		memtier = __node_get_memory_tier(node);
+		if (memtier) {
+			rcu_assign_pointer(pgdat->memtier, NULL);
+			synchronize_rcu();
+		}
+		node_clear(node, memtype->nodes);
+		if (nodes_empty(memtype->nodes)) {
+			list_del(&memtype->tier_sibiling);
+			memtype->memtier = NULL;
+			if (current_memtier && list_empty(&current_memtier->memory_types))
+				destroy_memory_tier(current_memtier);
+
+		}
+		node_memory_types[node] = NULL;
+	}
+	mutex_unlock(&memory_tier_lock);
+}
+EXPORT_SYMBOL_GPL(init_node_memory_type);
+
 void update_node_adistance(int node, struct memory_dev_type *memtype)
 {
 	pg_data_t *pgdat;

[back

Quoted 9 lines · Aneesh Kumar K V

Quoted 8 lines · Ying

Quoted 6 lines · Aneesh Kumar K V

Quoted 5 lines · Ying

Quoted 3 lines · Aneesh Kumar K.V

Quoted 1 line · Ying

"Aneesh Kumar K.V" <[email protected]> writes:

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

With the module unload, it is kind of force removing the usage of the specific memtype. Considering module unload will remove the usage of specific memtype from other parts of the kernel and we already do all the required reset in memory hot unplug, do we need to do the clear_node_memory_type above?

Quoted 6 lines

Quoted 4 lines

Per my understanding, we need to call clear_node_memory_type() in dev_dax_kmem_remove(). After that, we have nothing to do in dax_kmem_exit().

Ok, I guess you are suggesting to do the clear_node_memory_type even if we fail the memory remove.

Can we use node_memory_types[] to indicate whether a node is managed by a driver?

Regardless being succeeded or failed, dev_dax_kmem_remove() will set node_memory_types[] = NULL. But until node is offlined, we will still keep the node in the memory_dev_type (dax_pmem_type).

And we will prevent dax/kmem from unloading via try_module_get() and add "struct module *" to struct memory_dev_type.

Quoted 11 lines · Ying

Quoted 9 lines · Aneesh Kumar K V

Quoted 8 lines · Ying

Quoted 6 lines · Aneesh Kumar K V

Quoted 5 lines · Ying

Quoted 3 lines · Aneesh Kumar K.V

Quoted 1 line · Ying

"Aneesh Kumar K.V" <[email protected]> writes:

....

Quoted 16 lines

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

With the module unload, it is kind of force removing the usage of the specific memtype. Considering module unload will remove the usage of specific memtype from other parts of the kernel and we already do all the required reset in memory hot unplug, do we need to do the clear_node_memory_type above?

Quoted 6 lines

Quoted 4 lines

Per my understanding, we need to call clear_node_memory_type() in dev_dax_kmem_remove(). After that, we have nothing to do in dax_kmem_exit().

Ok, I guess you are suggesting to do the clear_node_memory_type even if we fail the memory remove.

Can we use node_memory_types[] to indicate whether a node is managed by a driver?

Quoted 7 lines

Regardless being succeeded or failed, dev_dax_kmem_remove() will set node_memory_types[] = NULL. But until node is offlined, we will still keep the node in the memory_dev_type (dax_pmem_type).

And we will prevent dax/kmem from unloading via try_module_get() and add "struct module *" to struct memory_dev_type.

Current dax/kmem driver is not holding any module reference and allows the module to be unloaded anytime. Even if the memory onlined by the driver fails to be unplugged. Addition of memory_dev_type as suggested by you will be different than that. Page demotion can continue to work without the support of dax_pmem_type as long as we keep the older demotion order. Any new demotion order rebuild will remove the the memory node which was not hotunplugged from the demotion order. Isn't that a much simpler implementation?

Quoted 39 lines · Aneesh Kumar K V

Quoted 11 lines · Ying

Quoted 9 lines · Aneesh Kumar K V

Quoted 8 lines · Ying

Quoted 6 lines · Aneesh Kumar K V

Quoted 5 lines · Ying

Quoted 3 lines · Aneesh Kumar K.V

Quoted 1 line · Ying

"Aneesh Kumar K.V" <[email protected]> writes:

....

Quoted 16 lines

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

With the module unload, it is kind of force removing the usage of the specific memtype. Considering module unload will remove the usage of specific memtype from other parts of the kernel and we already do all the required reset in memory hot unplug, do we need to do the clear_node_memory_type above?

Quoted 6 lines

Quoted 4 lines

Per my understanding, we need to call clear_node_memory_type() in dev_dax_kmem_remove(). After that, we have nothing to do in dax_kmem_exit().

Ok, I guess you are suggesting to do the clear_node_memory_type even if we fail the memory remove.

Can we use node_memory_types[] to indicate whether a node is managed by a driver?

Quoted 7 lines

Regardless being succeeded or failed, dev_dax_kmem_remove() will set node_memory_types[] = NULL. But until node is offlined, we will still keep the node in the memory_dev_type (dax_pmem_type).

And we will prevent dax/kmem from unloading via try_module_get() and add "struct module *" to struct memory_dev_type.

Quoted 6 lines

Current dax/kmem driver is not holding any module reference and allows the module to be unloaded anytime. Even if the memory onlined by the driver fails to be unplugged. Addition of memory_dev_type as suggested by you will be different than that. Page demotion can continue to work without the support of dax_pmem_type as long as we keep the older demotion order. Any new demotion order rebuild will remove the the memory node which was not hotunplugged from the demotion order. Isn't that a much simpler implementation?

Per my understanding, unbinding/binding the dax/kmem driver means changing the memory type of a memory device. For example, unbinding dax/kmem driver may mean changing the memory type from dax_pmem_type to default_memory_type (or default_dram_type). That appears strange. But if we force the NUMA node to be offlined for unbinding, we can avoid to change the memory type to default_memory_type.

Quoted 48 lines · Ying

Quoted 39 lines · Aneesh Kumar K V

Quoted 11 lines · Ying

Quoted 9 lines · Aneesh Kumar K V

Quoted 8 lines · Ying

Quoted 6 lines · Aneesh Kumar K V

Quoted 5 lines · Ying

Quoted 3 lines · Aneesh Kumar K.V

Quoted 1 line · Ying

"Aneesh Kumar K.V" <[email protected]> writes:

....

Quoted 16 lines

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

With the module unload, it is kind of force removing the usage of the specific memtype. Considering module unload will remove the usage of specific memtype from other parts of the kernel and we already do all the required reset in memory hot unplug, do we need to do the clear_node_memory_type above?

Quoted 6 lines

Quoted 4 lines

Per my understanding, we need to call clear_node_memory_type() in dev_dax_kmem_remove(). After that, we have nothing to do in dax_kmem_exit().

Ok, I guess you are suggesting to do the clear_node_memory_type even if we fail the memory remove.

Can we use node_memory_types[] to indicate whether a node is managed by a driver?

Quoted 7 lines

Regardless being succeeded or failed, dev_dax_kmem_remove() will set node_memory_types[] = NULL. But until node is offlined, we will still keep the node in the memory_dev_type (dax_pmem_type).

And we will prevent dax/kmem from unloading via try_module_get() and add "struct module *" to struct memory_dev_type.

Quoted 6 lines

Current dax/kmem driver is not holding any module reference and allows the module to be unloaded anytime. Even if the memory onlined by the driver fails to be unplugged. Addition of memory_dev_type as suggested by you will be different than that. Page demotion can continue to work without the support of dax_pmem_type as long as we keep the older demotion order. Any new demotion order rebuild will remove the the memory node which was not hotunplugged from the demotion order. Isn't that a much simpler implementation?

Quoted 7 lines

Per my understanding, unbinding/binding the dax/kmem driver means changing the memory type of a memory device. For example, unbinding dax/kmem driver may mean changing the memory type from dax_pmem_type to default_memory_type (or default_dram_type). That appears strange. But if we force the NUMA node to be offlined for unbinding, we can avoid to change the memory type to default_memory_type.

If we are able to unplug all the memory, we do remove the node from N_MEMORY. If we fail to unplug the memory, we have two options.

1) Keep the same demotion order
2) Rebuild the demotion order which results in memory NUMA node not participating in demotion.

I agree with you that we should not switch to default memory type.

The below code demonstrate how it can be done. If we want to keep the same demotion order, we can remove establish_demotion_target() from the below code.

void clear_node_memory_type(int node, struct memory_dev_type *memtype)

{
	struct memory_tier *memtier;
	pg_data_t *pgdat = NODE_DATA(node);

	mutex_lock(&memory_tier_lock);
	/*
	 * Even if we fail to unplug memory, clear the association of
	 * this node to this specific memory type.
	 */
	if (node_isset(node, memtype->nodes) && node_memory_types[node] == memtype) {

		memtier = __node_get_memory_tier(node);
		if (memtier) {
			rcu_assign_pointer(pgdat->memtier, NULL);
			synchronize_rcu();
		}
		node_clear(node, memtype->nodes);
		if (nodes_empty(memtype->nodes)) {
			list_del(&memtype->tier_sibiling);
			memtype->memtier = NULL;
			if (memtier && list_empty(&memtier->memory_types))
				destroy_memory_tier(memtier);

		}
		establish_demotion_targets();
	}
	node_memory_types[node] = NULL;
	mutex_unlock(&memory_tier_lock);
}

If we agree that we want to keep the current behavior (that is to allow kmem driver unload even on memory unplug failure) we can go with the above change. If we are suggesting we should prevent a driver unload, then IMHO it should be independent of memory_dev_type (or this patch series). We should make sure we take a module reference on successful memory online and drop it only on successful offline.

This patch switch the demotion target building logic to use memory tiers instead of NUMA distance. All N_MEMORY NUMA nodes will be placed in the default memory tier and additional memory tiers will be added by drivers like dax kmem.

This patch builds the demotion target for a NUMA node by looking at all memory tiers below the tier to which the NUMA node belongs. The closest node in the immediately following memory tier is used as a demotion target.

Since we are now only building demotion target for N_MEMORY NUMA nodes the CPU hotplug calls are removed in this patch.

Signed-off-by Aneesh Kumar K.V <[email protected]>

---
 include/linux/memory-tiers.h |  13 ++
 include/linux/migrate.h      |  13 --
 mm/memory-tiers.c            | 221 +++++++++++++++++++-
 mm/migrate.c                 | 394 -----------------------------------
 mm/vmstat.c                  |   4 -
 5 files changed, 233 insertions(+), 412 deletions(-)

include/linux/memory-tiers.h +13 -0

index 4f4baf0bf430..e56a57c6ef78 100644
@@ -31,6 +31,14 @@ struct memory_dev_type {
 #ifdef CONFIG_NUMA
 extern bool numa_demotion_enabled;
 struct memory_dev_type *init_node_memory_type(int node, struct memory_dev_type *default_type);
+#ifdef CONFIG_MIGRATION
+int next_demotion_node(int node);
+#else
+static inline int next_demotion_node(int node)
+{
+	return NUMA_NO_NODE;
+}
+#endif
 
 #else
 

@@ -39,5 +47,10 @@ static inline struct memory_dev_type *init_node_memory_type(int node, struct mem
 {
 	return ERR_PTR(-EINVAL);
 }
+
+static inline int next_demotion_node(int node)
+{
+	return NUMA_NO_NODE;
+}
 #endif	/* CONFIG_NUMA */
 #endif  /* _LINUX_MEMORY_TIERS_H */

include/linux/migrate.h +0 -13

index 43e737215f33..93fab62e6548 100644
@@ -75,19 +75,6 @@ static inline int migrate_huge_page_move_mapping(struct address_space *mapping,
 
 #endif /* CONFIG_MIGRATION */
 
-#if defined(CONFIG_MIGRATION) && defined(CONFIG_NUMA)
-extern void set_migration_target_nodes(void);
-extern void migrate_on_reclaim_init(void);
-extern int next_demotion_node(int node);
-#else
-static inline void set_migration_target_nodes(void) {}
-static inline void migrate_on_reclaim_init(void) {}
-static inline int next_demotion_node(int node)
-{
-        return NUMA_NO_NODE;
-}
-#endif
-
 #ifdef CONFIG_COMPACTION
 extern int PageMovable(struct page *page);
 extern void __SetPageMovable(struct page *page, struct address_space *mapping);

mm/memory-tiers.c +99 -0

index 109be75fa554..60845aa74afc 100644
@@ -2,8 +2,11 @@
 #include <linux/slab.h>
 #include <linux/lockdep.h>
 #include <linux/memory.h>
+#include <linux/random.h>
 #include <linux/memory-tiers.h>
 
+#include "internal.h"
+
 struct memory_tier {
 	/* hierarchy of memory tiers */
 	struct list_head list;

@@ -17,9 +20,74 @@ struct memory_tier {
 	int adistance_start;
 };
 
+struct demotion_nodes {
+	nodemask_t preferred;
+};
+
 static DEFINE_MUTEX(memory_tier_lock);
 static LIST_HEAD(memory_tiers);
 struct memory_dev_type *node_memory_types[MAX_NUMNODES];
+#ifdef CONFIG_MIGRATION
+/*
+ * node_demotion[] examples:
+ *
+ * Example 1:
+ *
+ * Node 0 & 1 are CPU + DRAM nodes, node 2 & 3 are PMEM nodes.
+ *
+ * node distances:
+ * node   0    1    2    3
+ *    0  10   20   30   40
+ *    1  20   10   40   30
+ *    2  30   40   10   40
+ *    3  40   30   40   10
+ *
+ * memory_tiers0 = 0-1
+ * memory_tiers1 = 2-3
+ *
+ * node_demotion[0].preferred = 2
+ * node_demotion[1].preferred = 3
+ * node_demotion[2].preferred = <empty>
+ * node_demotion[3].preferred = <empty>
+ *
+ * Example 2:
+ *
+ * Node 0 & 1 are CPU + DRAM nodes, node 2 is memory-only DRAM node.
+ *
+ * node distances:
+ * node   0    1    2
+ *    0  10   20   30
+ *    1  20   10   30
+ *    2  30   30   10
+ *
+ * memory_tiers0 = 0-2
+ *
+ * node_demotion[0].preferred = <empty>
+ * node_demotion[1].preferred = <empty>
+ * node_demotion[2].preferred = <empty>
+ *
+ * Example 3:
+ *
+ * Node 0 is CPU + DRAM nodes, Node 1 is HBM node, node 2 is PMEM node.
+ *
+ * node distances:
+ * node   0    1    2
+ *    0  10   20   30
+ *    1  20   10   40
+ *    2  30   40   10
+ *
+ * memory_tiers0 = 1
+ * memory_tiers1 = 0
+ * memory_tiers2 = 2
+ *
+ * node_demotion[0].preferred = 2
+ * node_demotion[1].preferred = 0
+ * node_demotion[2].preferred = <empty>
+ *
+ */
+static struct demotion_nodes *node_demotion __read_mostly;
+#endif /* CONFIG_MIGRATION */
+
 /*
  * For now let's have 4 memory tier below default DRAM tier.
  */

@@ -82,6 +150,144 @@ static struct memory_tier *__node_get_memory_tier(int node)
 	return NULL;
 }
 
+#ifdef CONFIG_MIGRATION
+/**
+ * next_demotion_node() - Get the next node in the demotion path
+ * @node: The starting node to lookup the next node
+ *
+ * Return: node id for next memory node in the demotion path hierarchy
+ * from @node; NUMA_NO_NODE if @node is terminal.  This does not keep
+ * @node online or guarantee that it *continues* to be the next demotion
+ * target.
+ */
+int next_demotion_node(int node)
+{
+	struct demotion_nodes *nd;
+	int target;
+
+	if (!node_demotion)
+		return NUMA_NO_NODE;
+
+	nd = &node_demotion[node];
+
+	/*
+	 * node_demotion[] is updated without excluding this
+	 * function from running.
+	 *
+	 * Make sure to use RCU over entire code blocks if
+	 * node_demotion[] reads need to be consistent.
+	 */
+	rcu_read_lock();
+	/*
+	 * If there are multiple target nodes, just select one
+	 * target node randomly.

mm/memory-tiers.c +111 -1

+	rcu_read_unlock();
+
+	return target;
+}
+
+static void disable_all_demotion_targets(void)
+{
+	int node;
+
+	for_each_node_state(node, N_MEMORY)
+		node_demotion[node].preferred = NODE_MASK_NONE;
+	/*
+	 * Ensure that the "disable" is visible across the system.
+	 * Readers will see either a combination of before+disable
+	 * state or disable+after.  They will never see before and
+	 * after state together.
+	 */
+	synchronize_rcu();
+}
+
+static __always_inline nodemask_t get_memtier_nodemask(struct memory_tier *memtier)
+{
+	nodemask_t nodes = NODE_MASK_NONE;
+	struct memory_dev_type *memtype;
+
+	list_for_each_entry(memtype, &memtier->memory_types, tier_sibiling)
+		nodes_or(nodes, nodes, memtype->nodes);
+
+	return nodes;
+}
+
+/*
+ * Find an automatic demotion target for all memory
+ * nodes. Failing here is OK.  It might just indicate
+ * being at the end of a chain.
+ */
+static void establish_demotion_targets(void)
+{
+	struct memory_tier *memtier;
+	struct demotion_nodes *nd;
+	int target = NUMA_NO_NODE, node;
+	int distance, best_distance;
+	nodemask_t tier_nodes;
+
+	lockdep_assert_held_once(&memory_tier_lock);
+
+	if (!node_demotion || !IS_ENABLED(CONFIG_MIGRATION))
+		return;
+
+	disable_all_demotion_targets();
+
+	for_each_node_state(node, N_MEMORY) {
+		best_distance = -1;
+		nd = &node_demotion[node];
+
+		memtier = __node_get_memory_tier(node);
+		if (!memtier || list_is_first(&memtier->list, &memory_tiers))
+			continue;
+		/*
+		 * Get the lower memtier to find the  demotion node list.
+		 */
+		memtier = list_prev_entry(memtier, list);
+		tier_nodes = get_memtier_nodemask(memtier);
+		/*
+		 * find_next_best_node, use 'used' nodemask as a skip list.
+		 * Add all memory nodes except the selected memory tier
+		 * nodelist to skip list so that we find the best node from the
+		 * memtier nodelist.
+		 */
+		nodes_andnot(tier_nodes, node_states[N_MEMORY], tier_nodes);
+
+		/*
+		 * Find all the nodes in the memory tier node list of same best distance.
+		 * add them to the preferred mask. We randomly select between nodes
+		 * in the preferred mask when allocating pages during demotion.
+		 */
+		do {
+			target = find_next_best_node(node, &tier_nodes);
+			if (target == NUMA_NO_NODE)
+				break;
+
+			distance = node_distance(node, target);
+			if (distance == best_distance || best_distance == -1) {
+				best_distance = distance;
+				node_set(target, nd->preferred);
+			} else {
+				break;
+			}
+		} while (1);
+	}
+}
+
+#else
+static inline void disable_all_demotion_targets(void) {}
+static inline void establish_demotion_targets(void) {}
+#endif /* CONFIG_MIGRATION */
+
 static void init_node_memory_tier(int node)
 {
 	struct memory_tier *memtier;

@@ -89,6 +295,13 @@ static void init_node_memory_tier(int node)
 	mutex_lock(&memory_tier_lock);
 
 	memtier = __node_get_memory_tier(node);
+	/*
+	 * if node is already part of the tier proceed with the
+	 * current tier value, because we might want to establish
+	 * new migration paths now. The node might be added to a tier
+	 * before it was made part of N_MEMORY, hence estabilish_demotion_targets
+	 * will have skipped this node.
+	 */
 	if (!memtier) {
 		struct memory_dev_type *memtype;
 

@@ -99,6 +312,7 @@ static void init_node_memory_tier(int node)
 		memtype = node_memory_types[node];
 		memtier = find_create_memory_tier(memtype);
 	}
+	establish_demotion_targets();
 	mutex_unlock(&memory_tier_lock);
 }
 

@@ -125,6 +339,7 @@ static void clear_node_memory_tier(int node)
 			if (list_empty(&current_memtier->memory_types))
 				destroy_memory_tier(current_memtier);
 		}
+		establish_demotion_targets();
 	}
 	mutex_unlock(&memory_tier_lock);
 }

@@ -182,7 +397,11 @@ static int __init memory_tier_init(void)
 		panic("%s() failed to register memory tier: %ld\n",
 		      __func__, PTR_ERR(memtier));
 	mutex_unlock(&memory_tier_lock);
-
+#ifdef CONFIG_MIGRATION
+	node_demotion = kcalloc(MAX_NUMNODES, sizeof(struct demotion_nodes),
+				GFP_KERNEL);
+	WARN_ON(!node_demotion);
+#endif
 	hotplug_memory_notifier(memtier_hotplug_callback, MEMTIER_HOTPLUG_PRIO);
 	return 0;
 }

mm/migrate.c +0 -394

index fce7d4a9e940..c758c9c21d7d 100644
@@ -2117,398 +2117,4 @@ int migrate_misplaced_page(struct page *page, struct vm_area_struct *vma,
 	return 0;
 }
 #endif /* CONFIG_NUMA_BALANCING */
-
-/*
- * node_demotion[] example:
- *
- * Consider a system with two sockets.  Each socket has
- * three classes of memory attached: fast, medium and slow.
- * Each memory class is placed in its own NUMA node.  The
- * CPUs are placed in the node with the "fast" memory.  The
- * 6 NUMA nodes (0-5) might be split among the sockets like
- * this:
- *
- *	Socket A: 0, 1, 2
- *	Socket B: 3, 4, 5
- *
- * When Node 0 fills up, its memory should be migrated to
- * Node 1.  When Node 1 fills up, it should be migrated to
- * Node 2.  The migration path start on the nodes with the
- * processors (since allocations default to this node) and
- * fast memory, progress through medium and end with the
- * slow memory:
- *
- *	0 -> 1 -> 2 -> stop
- *	3 -> 4 -> 5 -> stop
- *
- * This is represented in the node_demotion[] like this:
- *
- *	{  nr=1, nodes[0]=1 }, // Node 0 migrates to 1
- *	{  nr=1, nodes[0]=2 }, // Node 1 migrates to 2
- *	{  nr=0, nodes[0]=-1 }, // Node 2 does not migrate
- *	{  nr=1, nodes[0]=4 }, // Node 3 migrates to 4
- *	{  nr=1, nodes[0]=5 }, // Node 4 migrates to 5
- *	{  nr=0, nodes[0]=-1 }, // Node 5 does not migrate
- *
- * Moreover some systems may have multiple slow memory nodes.
- * Suppose a system has one socket with 3 memory nodes, node 0
- * is fast memory type, and node 1/2 both are slow memory
- * type, and the distance between fast memory node and slow
- * memory node is same. So the migration path should be:
- *
- *	0 -> 1/2 -> stop
- *
- * This is represented in the node_demotion[] like this:
- *	{ nr=2, {nodes[0]=1, nodes[1]=2} }, // Node 0 migrates to node 1 and node 2
- *	{ nr=0, nodes[0]=-1, }, // Node 1 dose not migrate
- *	{ nr=0, nodes[0]=-1, }, // Node 2 does not migrate
- */
-
-/*
- * Writes to this array occur without locking.  Cycles are
- * not allowed: Node X demotes to Y which demotes to X...
- *
- * If multiple reads are performed, a single rcu_read_lock()
- * must be held over all reads to ensure that no cycles are
- * observed.
- */
-#define DEFAULT_DEMOTION_TARGET_NODES 15
-
-#if MAX_NUMNODES < DEFAULT_DEMOTION_TARGET_NODES
-#define DEMOTION_TARGET_NODES	(MAX_NUMNODES - 1)
-#else
-#define DEMOTION_TARGET_NODES	DEFAULT_DEMOTION_TARGET_NODES
-#endif
-
-struct demotion_nodes {
-	unsigned short nr;
-	short nodes[DEMOTION_TARGET_NODES];
-};
-
-static struct demotion_nodes *node_demotion __read_mostly;
-
-/**
- * next_demotion_node() - Get the next node in the demotion path
- * @node: The starting node to lookup the next node
- *
- * Return: node id for next memory node in the demotion path hierarchy
- * from @node; NUMA_NO_NODE if @node is terminal.  This does not keep
- * @node online or guarantee that it *continues* to be the next demotion
- * target.
- */
-int next_demotion_node(int node)
-{
-	struct demotion_nodes *nd;
-	unsigned short target_nr, index;
-	int target;
-
-	if (!node_demotion)
-		return NUMA_NO_NODE;
-
-	nd = &node_demotion[node];
-
-	/*
-	 * node_demotion[] is updated without excluding this
-	 * function from running.  RCU doesn't provide any
-	 * compiler barriers, so the READ_ONCE() is required
-	 * to avoid compiler reordering or read merging.
-	 *
-	 * Make sure to use RCU over entire code blocks if
-	 * node_demotion[] reads need to be consistent.
-	 */
-	rcu_read_lock();
-	target_nr = READ_ONCE(nd->nr);
-
-	switch (target_nr) {
-	case 0:
-		target = NUMA_NO_NODE;
-		goto out;
-	case 1:
-		index = 0;
-		break;
-	default:
-		/*
-		 * If there are multiple target nodes, just select one
-		 * target node randomly.
-		 *
-		 * In addition, we can also use round-robin to select
-		 * target node, but we should introduce another variable
-		 * for node_demotion[] to record last selected target node,
-		 * that may cause cache ping-pong due to the changing of
-		 * last target node. Or introducing per-cpu data to avoid
-		 * caching issue, which seems more complicated. So selecting
-		 * target node randomly seems better until now.
-		 */
-		index = get_random_int() % target_nr;
-		break;
-	}
-
-	target = READ_ONCE(nd->nodes[index]);
-
-out:
-	rcu_read_unlock();
-	return target;
-}
-
-/* Disable reclaim-based migration. */
-static void __disable_all_migrate_targets(void)
-{
-	int node, i;
-
-	if (!node_demotion)
-		return;
-
-	for_each_online_node(node) {
-		node_demotion[node].nr = 0;
-		for (i = 0; i < DEMOTION_TARGET_NODES; i++)
-			node_demotion[node].nodes[i] = NUMA_NO_NODE;
-	}
-}
-
-static void disable_all_migrate_targets(void)
-{
-	__disable_all_migrate_targets();
-
-	/*
-	 * Ensure that the "disable" is visible across the system.
-	 * Readers will see either a combination of before+disable
-	 * state or disable+after.  They will never see before and
-	 * after state together.
-	 *
-	 * The before+after state together might have cycles and
-	 * could cause readers to do things like loop until this
-	 * function finishes.  This ensures they can only see a
-	 * single "bad" read and would, for instance, only loop
-	 * once.
-	 */
-	synchronize_rcu();
-}
-
-/*
- * Find an automatic demotion target for 'node'.
- * Failing here is OK.  It might just indicate
- * being at the end of a chain.
- */
-static int establish_migrate_target(int node, nodemask_t *used,
-				    int best_distance)
-{
-	int migration_target, index, val;
-	struct demotion_nodes *nd;
-
-	if (!node_demotion)
-		return NUMA_NO_NODE;
-
-	nd = &node_demotion[node];
-
-	migration_target = find_next_best_node(node, used);
-	if (migration_target == NUMA_NO_NODE)
-		return NUMA_NO_NODE;
-
-	/*
-	 * If the node has been set a migration target node before,
-	 * which means it's the best distance between them. Still
-	 * check if this node can be demoted to other target nodes
-	 * if they have a same best distance.
-	 */
-	if (best_distance != -1) {
-		val = node_distance(node, migration_target);
-		if (val > best_distance)
-			goto out_clear;
-	}
-
-	index = nd->nr;
-	if (WARN_ONCE(index >= DEMOTION_TARGET_NODES,
-		      "Exceeds maximum demotion target nodes\n"))
-		goto out_clear;
-
-	nd->nodes[index] = migration_target;
-	nd->nr++;
-
-	return migration_target;
-out_clear:
-	node_clear(migration_target, *used);
-	return NUMA_NO_NODE;
-}
-
-/*
- * When memory fills up on a node, memory contents can be
- * automatically migrated to another node instead of
- * discarded at reclaim.
- *
- * Establish a "migration path" which will start at nodes
- * with CPUs and will follow the priorities used to build the
- * page allocator zonelists.
- *
- * The difference here is that cycles must be avoided.  If
- * node0 migrates to node1, then neither node1, nor anything
- * node1 migrates to can migrate to node0. Also one node can
- * be migrated to multiple nodes if the target nodes all have
- * a same best-distance against the source node.
- *
- * This function can run simultaneously with readers of
- * node_demotion[].  However, it can not run simultaneously
- * with itself.  Exclusion is provided by memory hotplug events
- * being single-threaded.
- */
-static void __set_migration_target_nodes(void)
-{
-	nodemask_t next_pass;
-	nodemask_t this_pass;
-	nodemask_t used_targets = NODE_MASK_NONE;
-	int node, best_distance;
-
-	/*
-	 * Avoid any oddities like cycles that could occur
-	 * from changes in the topology.  This will leave
-	 * a momentary gap when migration is disabled.
-	 */
-	disable_all_migrate_targets();
-
-	/*
-	 * Allocations go close to CPUs, first.  Assume that
-	 * the migration path starts at the nodes with CPUs.
-	 */
-	next_pass = node_states[N_CPU];
-again:
-	this_pass = next_pass;
-	next_pass = NODE_MASK_NONE;
-	/*
-	 * To avoid cycles in the migration "graph", ensure
-	 * that migration sources are not future targets by
-	 * setting them in 'used_targets'.  Do this only
-	 * once per pass so that multiple source nodes can
-	 * share a target node.
-	 *
-	 * 'used_targets' will become unavailable in future
-	 * passes.  This limits some opportunities for
-	 * multiple source nodes to share a destination.
-	 */
-	nodes_or(used_targets, used_targets, this_pass);
-
-	for_each_node_mask(node, this_pass) {
-		best_distance = -1;
-
-		/*
-		 * Try to set up the migration path for the node, and the target
-		 * migration nodes can be multiple, so doing a loop to find all
-		 * the target nodes if they all have a best node distance.
-		 */
-		do {
-			int target_node =
-				establish_migrate_target(node, &used_targets,
-							 best_distance);
-
-			if (target_node == NUMA_NO_NODE)
-				break;
-
-			if (best_distance == -1)
-				best_distance = node_distance(node, target_node);
-
-			/*
-			 * Visit targets from this pass in the next pass.
-			 * Eventually, every node will have been part of
-			 * a pass, and will become set in 'used_targets'.
-			 */
-			node_set(target_node, next_pass);
-		} while (1);
-	}
-	/*
-	 * 'next_pass' contains nodes which became migration
-	 * targets in this pass.  Make additional passes until
-	 * no more migrations targets are available.
-	 */
-	if (!nodes_empty(next_pass))
-		goto again;
-}
-
-/*
- * For callers that do not hold get_online_mems() already.
- */
-void set_migration_target_nodes(void)
-{
-	get_online_mems();
-	__set_migration_target_nodes();
-	put_online_mems();
-}
-
-/*
- * This leaves migrate-on-reclaim transiently disabled between
- * the MEM_GOING_OFFLINE and MEM_OFFLINE events.  This runs
- * whether reclaim-based migration is enabled or not, which
- * ensures that the user can turn reclaim-based migration at
- * any time without needing to recalculate migration targets.
- *
- * These callbacks already hold get_online_mems().  That is why
- * __set_migration_target_nodes() can be used as opposed to
- * set_migration_target_nodes().
- */
-#ifdef CONFIG_MEMORY_HOTPLUG
-static int __meminit migrate_on_reclaim_callback(struct notifier_block *self,
-						 unsigned long action, void *_arg)
-{
-	struct memory_notify *arg = _arg;
-
-	/*
-	 * Only update the node migration order when a node is
-	 * changing status, like online->offline.  This avoids
-	 * the overhead of synchronize_rcu() in most cases.
-	 */
-	if (arg->status_change_nid < 0)
-		return notifier_from_errno(0);
-
-	switch (action) {
-	case MEM_GOING_OFFLINE:
-		/*
-		 * Make sure there are not transient states where
-		 * an offline node is a migration target.  This
-		 * will leave migration disabled until the offline
-		 * completes and the MEM_OFFLINE case below runs.
-		 */
-		disable_all_migrate_targets();
-		break;
-	case MEM_OFFLINE:
-	case MEM_ONLINE:
-		/*
-		 * Recalculate the target nodes once the node
-		 * reaches its final state (online or offline).
-		 */
-		__set_migration_target_nodes();
-		break;
-	case MEM_CANCEL_OFFLINE:
-		/*
-		 * MEM_GOING_OFFLINE disabled all the migration
-		 * targets.  Reenable them.
-		 */
-		__set_migration_target_nodes();
-		break;
-	case MEM_GOING_ONLINE:
-	case MEM_CANCEL_ONLINE:
-		break;
-	}
-
-	return notifier_from_errno(0);
-}
-#endif
-
-void __init migrate_on_reclaim_init(void)
-{
-	node_demotion = kcalloc(nr_node_ids,
-				sizeof(struct demotion_nodes),
-				GFP_KERNEL);
-	WARN_ON(!node_demotion);
-#ifdef CONFIG_MEMORY_HOTPLUG
-	hotplug_memory_notifier(migrate_on_reclaim_callback, 100);
-#endif
-	/*
-	 * At this point, all numa nodes with memory/CPus have their state
-	 * properly set, so we can build the demotion order now.
-	 * Let us hold the cpu_hotplug lock just, as we could possibily have
-	 * CPU hotplug events during boot.
-	 */
-	cpus_read_lock();
-	set_migration_target_nodes();
-	cpus_read_unlock();
-}
 #endif /* CONFIG_NUMA */
-
-

mm/vmstat.c +0 -4

index 373d2730fcf2..35c6ff97cf29 100644
@@ -28,7 +28,6 @@
 #include <linux/mm_inline.h>
 #include <linux/page_ext.h>
 #include <linux/page_owner.h>
-#include <linux/migrate.h>
 
 #include "internal.h"
 

@@ -2060,7 +2059,6 @@ static int vmstat_cpu_online(unsigned int cpu)
 
 	if (!node_state(cpu_to_node(cpu), N_CPU)) {
 		node_set_state(cpu_to_node(cpu), N_CPU);
-		set_migration_target_nodes();
 	}
 
 	return 0;

@@ -2085,7 +2083,6 @@ static int vmstat_cpu_dead(unsigned int cpu)
 		return 0;
 
 	node_clear_state(node, N_CPU);
-	set_migration_target_nodes();
 
 	return 0;
 }

@@ -2118,7 +2115,6 @@ void __init init_mm_internals(void)
 
 	start_shepherd_timer();
 #endif
-	migrate_on_reclaim_init();
 #ifdef CONFIG_PROC_FS
 	proc_create_seq("buddyinfo", 0444, NULL, &fragmentation_op);
 	proc_create_seq("pagetypeinfo", 0400, NULL, &pagetypeinfo_op);

"Aneesh Kumar K.V" <[email protected]> writes:
+ */

Quoted 26 lines

mm/memory-tiers.c +26 -0

+int next_demotion_node(int node)
+{
+	struct demotion_nodes *nd;
+	int target;
+
+	if (!node_demotion)
+		return NUMA_NO_NODE;
+
+	nd = &node_demotion[node];
+
+	/*
+	 * node_demotion[] is updated without excluding this
+	 * function from running.
+	 *
+	 * Make sure to use RCU over entire code blocks if
+	 * node_demotion[] reads need to be consistent.
+	 */
+	rcu_read_lock();
+	/*
+	 * If there are multiple target nodes, just select one
+	 * target node randomly.
+	 *
+	 * In addition, we can also use round-robin to select
+	 * target node, but we should introduce another variable
+	 * for node_demotion[] to record last selected target node,
+	 * that may cause cache ping-pong due to the changing of

mm/memory-tiers.c static struct memory_tier *__node_get_memory_tier(int node) · line 193

Quoted 5 lines

mm/memory-tiers.c +5 -0

+	 * last target node. Or introducing per-cpu data to avoid
+	 * caching issue, which seems more complicated. So selecting
+	 * target node randomly seems better until now.
+	 */
+	target = node_random(&nd->preferred);

Don't find code to optimize node_random() for weight == 1 case, forget to do that?

Quoted 2 lines · Ying

"Aneesh Kumar K.V" <[email protected]> writes:
+ */

....

Quoted 26 lines

Quoted 26 lines

mm/memory-tiers.c +26 -0

+int next_demotion_node(int node)
+{
+	struct demotion_nodes *nd;
+	int target;
+
+	if (!node_demotion)
+		return NUMA_NO_NODE;
+
+	nd = &node_demotion[node];
+
+	/*
+	 * node_demotion[] is updated without excluding this
+	 * function from running.
+	 *
+	 * Make sure to use RCU over entire code blocks if
+	 * node_demotion[] reads need to be consistent.
+	 */
+	rcu_read_lock();
+	/*
+	 * If there are multiple target nodes, just select one
+	 * target node randomly.
+	 *
+	 * In addition, we can also use round-robin to select
+	 * target node, but we should introduce another variable
+	 * for node_demotion[] to record last selected target node,
+	 * that may cause cache ping-pong due to the changing of

Quoted 8 lines

mm/memory-tiers.c static struct memory_tier *__node_get_memory_tier(int node) · line 193

Quoted 5 lines

mm/memory-tiers.c +5 -0

+	 * last target node. Or introducing per-cpu data to avoid
+	 * caching issue, which seems more complicated. So selecting
+	 * target node randomly seems better until now.
+	 */
+	target = node_random(&nd->preferred);

Don't find code to optimize node_random() for weight == 1 case, forget to do that?

I guess you suggested to do that as the patch for node_random or did I got the review feedback wrong?

https://lore.kernel.org/linux-mm/[email protected]

The change for node_random will be patch outside this series.