Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1617366 > unrolled thread

[HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory Jérôme Glisse <jglisse@redhat.com> - 2017-04-05 22:50 +0200
    Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to  arch_add/remove_memory Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-04-06 11:50 +0200
      Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to  arch_add/remove_memory Jerome Glisse <jglisse@redhat.com> - 2017-04-06 16:00 +0200
    Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to  arch_add/remove_memory Michal Hocko <mhocko@kernel.org> - 2017-04-07 14:20 +0200
      Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to  arch_add/remove_memory Jerome Glisse <jglisse@redhat.com> - 2017-04-07 16:40 +0200
        Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to  arch_add/remove_memory Michal Hocko <mhocko@kernel.org> - 2017-04-07 16:50 +0200
          Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to  arch_add/remove_memory Jerome Glisse <jglisse@redhat.com> - 2017-04-07 17:00 +0200
            Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to  arch_add/remove_memory Michal Hocko <mhocko@kernel.org> - 2017-04-07 17:20 +0200
              Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to  arch_add/remove_memory Jerome Glisse <jglisse@redhat.com> - 2017-04-07 18:20 +0200
                Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to  arch_add/remove_memory Michal Hocko <mhocko@kernel.org> - 2017-04-07 18:40 +0200
                  Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to  arch_add/remove_memory Jerome Glisse <jglisse@redhat.com> - 2017-04-07 19:20 +0200
                    Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to  arch_add/remove_memory Michal Hocko <mhocko@kernel.org> - 2017-04-07 20:00 +0200
                      Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to  arch_add/remove_memory Jerome Glisse <jglisse@redhat.com> - 2017-04-07 20:30 +0200

#1617366 — [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

When hotpluging memory we want more information on the type of memory.
This is to extend ZONE_DEVICE to support new type of memory other than
the persistent memory. Existing user of ZONE_DEVICE (persistent memory)
will be left un-modified.

Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
---
 arch/ia64/mm/init.c            | 36 +++++++++++++++++++++++++++++++++---
 arch/powerpc/mm/mem.c          | 37 ++++++++++++++++++++++++++++++++++---
 arch/s390/mm/init.c            | 16 ++++++++++++++--
 arch/sh/mm/init.c              | 35 +++++++++++++++++++++++++++++++++--
 arch/x86/mm/init_32.c          | 41 +++++++++++++++++++++++++++++++++++++----
 arch/x86/mm/init_64.c          | 39 +++++++++++++++++++++++++++++++++++----
 include/linux/memory_hotplug.h | 24 ++++++++++++++++++++++--
 include/linux/memremap.h       |  2 ++
 kernel/memremap.c              |  5 +++--
 mm/memory_hotplug.c            |  4 ++--
 10 files changed, 215 insertions(+), 24 deletions(-)

diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index 06cdaef..c910b3f 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -645,20 +645,36 @@ mem_init (void)
 }
 
 #ifdef CONFIG_MEMORY_HOTPLUG
-int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
+int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
 {
 	pg_data_t *pgdat;
 	struct zone *zone;
 	unsigned long start_pfn = start >> PAGE_SHIFT;
 	unsigned long nr_pages = size >> PAGE_SHIFT;
+	bool for_device = false;
 	int ret;
 
+	/*
+	 * Each memory_type needs special handling, so error out on an
+	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
+	 * is not supported on this architecture.
+	 */
+	switch (type) {
+	case MEMORY_NORMAL:
+		break;
+	case MEMORY_DEVICE_PERSISTENT:
+		for_device = true;
+		break;
+	default:
+		pr_err("hotplug unsupported memory type %d\n", type);
+		return -EINVAL;
+	}
+
 	pgdat = NODE_DATA(nid);
 
 	zone = pgdat->node_zones +
 		zone_for_memory(nid, start, size, ZONE_NORMAL, for_device);
 	ret = __add_pages(nid, zone, start_pfn, nr_pages);
-
 	if (ret)
 		printk("%s: Problem encountered in __add_pages() as ret=%d\n",
 		       __func__,  ret);
@@ -667,13 +683,27 @@ int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
 }
 
 #ifdef CONFIG_MEMORY_HOTREMOVE
-int arch_remove_memory(u64 start, u64 size)
+int arch_remove_memory(u64 start, u64 size, enum memory_type type)
 {
 	unsigned long start_pfn = start >> PAGE_SHIFT;
 	unsigned long nr_pages = size >> PAGE_SHIFT;
 	struct zone *zone;
 	int ret;
 
+	/*
+	 * Each memory_type needs special handling, so error out on an
+	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
+	 * is not supported on this architecture.
+	 */
+	switch (type) {
+	case MEMORY_NORMAL:
+	case MEMORY_DEVICE_PERSISTENT:
+		break;
+	default:
+		pr_err("hotplug unsupported memory type %d\n", type);
+		return -EINVAL;
+	}
+
 	zone = page_zone(pfn_to_page(start_pfn));
 	ret = __remove_pages(zone, start_pfn, nr_pages);
 	if (ret)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 5f84433..0933261 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -126,14 +126,31 @@ int __weak remove_section_mapping(unsigned long start, unsigned long end)
 	return -ENODEV;
 }
 
-int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
+int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
 {
 	struct pglist_data *pgdata;
-	struct zone *zone;
 	unsigned long start_pfn = start >> PAGE_SHIFT;
 	unsigned long nr_pages = size >> PAGE_SHIFT;
+	bool for_device = false;
+	struct zone *zone;
 	int rc;
 
+	/*
+	 * Each memory_type needs special handling, so error out on an
+	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
+	 * is not supported on this architecture.
+	 */
+	switch (type) {
+	case MEMORY_NORMAL:
+		break;
+	case MEMORY_DEVICE_PERSISTENT:
+		for_device = true;
+		break;
+	default:
+		pr_err("hotplug unsupported memory type %d\n", type);
+		return -EINVAL;
+	}
+
 	pgdata = NODE_DATA(nid);
 
 	start = (unsigned long)__va(start);
@@ -153,13 +170,27 @@ int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
 }
 
 #ifdef CONFIG_MEMORY_HOTREMOVE
-int arch_remove_memory(u64 start, u64 size)
+int arch_remove_memory(u64 start, u64 size, enum memory_type type)
 {
 	unsigned long start_pfn = start >> PAGE_SHIFT;
 	unsigned long nr_pages = size >> PAGE_SHIFT;
 	struct zone *zone;
 	int ret;
 
+	/*
+	 * Each memory_type needs special handling, so error out on an
+	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
+	 * is not supported on this architecture.
+	 */
+	switch (type) {
+	case MEMORY_NORMAL:
+	case MEMORY_DEVICE_PERSISTENT:
+		break;
+	default:
+		pr_err("hotplug unsupported memory type %d\n", type);
+		return -EINVAL;
+	}
+
 	zone = page_zone(pfn_to_page(start_pfn));
 	ret = __remove_pages(zone, start_pfn, nr_pages);
 	if (ret)
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index bf5b8a0..20d7714 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -153,7 +153,7 @@ void __init free_initrd_mem(unsigned long start, unsigned long end)
 #endif
 
 #ifdef CONFIG_MEMORY_HOTPLUG
-int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
+int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
 {
 	unsigned long zone_start_pfn, zone_end_pfn, nr_pages;
 	unsigned long start_pfn = PFN_DOWN(start);
@@ -162,6 +162,18 @@ int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
 	struct zone *zone;
 	int rc, i;
 
+	/*
+	 * Each memory_type needs special handling, so error out on an
+	 * unsupported type.
+	 */
+	switch (type) {
+	case MEMORY_NORMAL:
+		break;
+	default:
+		pr_err("hotplug unsupported memory type %d\n", type);
+		return -EINVAL;
+	}
+
 	rc = vmem_add_mapping(start, size);
 	if (rc)
 		return rc;
@@ -205,7 +217,7 @@ unsigned long memory_block_size_bytes(void)
 }
 
 #ifdef CONFIG_MEMORY_HOTREMOVE
-int arch_remove_memory(u64 start, u64 size)
+int arch_remove_memory(u64 start, u64 size, enum memory_type type)
 {
 	/*
 	 * There is no hardware or firmware interface which could trigger a
diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
index 7549186..f37e7a6 100644
--- a/arch/sh/mm/init.c
+++ b/arch/sh/mm/init.c
@@ -485,13 +485,30 @@ void free_initrd_mem(unsigned long start, unsigned long end)
 #endif
 
 #ifdef CONFIG_MEMORY_HOTPLUG
-int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
+int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
 {
 	pg_data_t *pgdat;
 	unsigned long start_pfn = PFN_DOWN(start);
 	unsigned long nr_pages = size >> PAGE_SHIFT;
+	bool for_device = false;
 	int ret;
 
+	/*
+	 * Each memory_type needs special handling, so error out on an
+	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
+	 * is not supported on this architecture.
+	 */
+	switch (type) {
+	case MEMORY_NORMAL:
+		break;
+	case MEMORY_DEVICE_PERSISTENT:
+		for_device = true;
+		break;
+	default:
+		pr_err("hotplug unsupported memory type %d\n", type);
+		return -EINVAL;
+	}
+
 	pgdat = NODE_DATA(nid);
 
 	/* We only have ZONE_NORMAL, so this is easy.. */
@@ -516,13 +533,27 @@ EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
 #endif
 
 #ifdef CONFIG_MEMORY_HOTREMOVE
-int arch_remove_memory(u64 start, u64 size)
+int arch_remove_memory(u64 start, u64 size, enum memory_type type)
 {
 	unsigned long start_pfn = PFN_DOWN(start);
 	unsigned long nr_pages = size >> PAGE_SHIFT;
 	struct zone *zone;
 	int ret;
 
+	/*
+	 * Each memory_type needs special handling, so error out on an
+	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
+	 * is not supported on this architecture.
+	 */
+	switch (type) {
+	case MEMORY_NORMAL:
+	case MEMORY_DEVICE_PERSISTENT:
+		break;
+	default:
+		pr_err("hotplug unsupported memory type %d\n", type);
+		return -EINVAL;
+	}
+
 	zone = page_zone(pfn_to_page(start_pfn));
 	ret = __remove_pages(zone, start_pfn, nr_pages);
 	if (unlikely(ret))
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index c68078f..811d631 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -826,24 +826,57 @@ void __init mem_init(void)
 }
 
 #ifdef CONFIG_MEMORY_HOTPLUG
-int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
+int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
 {
 	struct pglist_data *pgdata = NODE_DATA(nid);
-	struct zone *zone = pgdata->node_zones +
-		zone_for_memory(nid, start, size, ZONE_HIGHMEM, for_device);
 	unsigned long start_pfn = start >> PAGE_SHIFT;
 	unsigned long nr_pages = size >> PAGE_SHIFT;
+	bool for_device = false;
+	struct zone *zone;
+
+	/*
+	 * Each memory_type needs special handling, so error out on an
+	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
+	 * is not supported on this architecture.
+	 */
+	switch (type) {
+	case MEMORY_NORMAL:
+		break;
+	case MEMORY_DEVICE_PERSISTENT:
+		for_device = true;
+		break;
+	default:
+		pr_err("hotplug unsupported memory type %d\n", type);
+		return -EINVAL;
+	}
+
+	zone = pgdata->node_zones +
+		zone_for_memory(nid, start, size, ZONE_HIGHMEM, for_device);
 
 	return __add_pages(nid, zone, start_pfn, nr_pages);
 }
 
 #ifdef CONFIG_MEMORY_HOTREMOVE
-int arch_remove_memory(u64 start, u64 size)
+int arch_remove_memory(u64 start, u64 size, enum memory_type type)
 {
 	unsigned long start_pfn = start >> PAGE_SHIFT;
 	unsigned long nr_pages = size >> PAGE_SHIFT;
 	struct zone *zone;
 
+	/*
+	 * Each memory_type needs special handling, so error out on an
+	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
+	 * is not supported on this architecture.
+	 */
+	switch (type) {
+	case MEMORY_NORMAL:
+	case MEMORY_DEVICE_PERSISTENT:
+		break;
+	default:
+		pr_err("hotplug unsupported memory type %d\n", type);
+		return -EINVAL;
+	}
+
 	zone = page_zone(pfn_to_page(start_pfn));
 	return __remove_pages(zone, start_pfn, nr_pages);
 }
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 7eef172..6c0b24e 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -641,15 +641,33 @@ static void  update_end_of_memory_vars(u64 start, u64 size)
  * Memory is added always to NORMAL zone. This means you will never get
  * additional DMA/DMA32 memory.
  */
-int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
+int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
 {
 	struct pglist_data *pgdat = NODE_DATA(nid);
-	struct zone *zone = pgdat->node_zones +
-		zone_for_memory(nid, start, size, ZONE_NORMAL, for_device);
 	unsigned long start_pfn = start >> PAGE_SHIFT;
 	unsigned long nr_pages = size >> PAGE_SHIFT;
+	bool for_device = false;
+	struct zone *zone;
 	int ret;
 
+	/*
+	 * Each memory_type needs special handling, so error out on an
+	 * unsupported type.
+	 */
+	switch (type) {
+	case MEMORY_NORMAL:
+		break;
+	case MEMORY_DEVICE_PERSISTENT:
+		for_device = true;
+		break;
+	default:
+		pr_err("hotplug unsupported memory type %d\n", type);
+		return -EINVAL;
+	}
+
+	zone = pgdat->node_zones +
+		zone_for_memory(nid, start, size, ZONE_NORMAL, for_device);
+
 	init_memory_mapping(start, start + size);
 
 	ret = __add_pages(nid, zone, start_pfn, nr_pages);
@@ -946,7 +964,7 @@ kernel_physical_mapping_remove(unsigned long start, unsigned long end)
 	remove_pagetable(start, end, true);
 }
 
-int __ref arch_remove_memory(u64 start, u64 size)
+int __ref arch_remove_memory(u64 start, u64 size, enum memory_type type)
 {
 	unsigned long start_pfn = start >> PAGE_SHIFT;
 	unsigned long nr_pages = size >> PAGE_SHIFT;
@@ -955,6 +973,19 @@ int __ref arch_remove_memory(u64 start, u64 size)
 	struct zone *zone;
 	int ret;
 
+	/*
+	 * Each memory_type needs special handling, so error out on an
+	 * unsupported type.
+	 */
+	switch (type) {
+	case MEMORY_NORMAL:
+	case MEMORY_DEVICE_PERSISTENT:
+		break;
+	default:
+		pr_err("hotplug unsupported memory type %d\n", type);
+		return -EINVAL;
+	}
+
 	/* With altmap the first mapped page is offset from @start */
 	altmap = to_vmem_altmap((unsigned long) page);
 	if (altmap)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 134a2f6..c3999f2 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -13,6 +13,26 @@ struct mem_section;
 struct memory_block;
 struct resource;
 
+/*
+ * When hotplugging memory with arch_add_memory(), we want more information on
+ * the type of memory we are hotplugging, because depending on the type of
+ * architecture, the code might want to take different paths.
+ *
+ * MEMORY_NORMAL:
+ * Your regular system memory. Default common case.
+ *
+ * MEMORY_DEVICE_PERSISTENT:
+ * Persistent device memory (pmem): struct page might be allocated in different
+ * memory and architecture might want to perform special actions. It is similar
+ * to regular memory, in that the CPU can access it transparently. However,
+ * it is likely to have different bandwidth and latency than regular memory.
+ * See Documentation/nvdimm/nvdimm.txt for more information.
+ */
+enum memory_type {
+	MEMORY_NORMAL = 0,
+	MEMORY_DEVICE_PERSISTENT,
+};
+
 #ifdef CONFIG_MEMORY_HOTPLUG
 
 /*
@@ -104,7 +124,7 @@ extern bool memhp_auto_online;
 
 #ifdef CONFIG_MEMORY_HOTREMOVE
 extern bool is_pageblock_removable_nolock(struct page *page);
-extern int arch_remove_memory(u64 start, u64 size);
+extern int arch_remove_memory(u64 start, u64 size, enum memory_type type);
 extern int __remove_pages(struct zone *zone, unsigned long start_pfn,
 	unsigned long nr_pages);
 #endif /* CONFIG_MEMORY_HOTREMOVE */
@@ -276,7 +296,7 @@ extern int add_memory(int nid, u64 start, u64 size);
 extern int add_memory_resource(int nid, struct resource *resource, bool online);
 extern int zone_for_memory(int nid, u64 start, u64 size, int zone_default,
 		bool for_device);
-extern int arch_add_memory(int nid, u64 start, u64 size, bool for_device);
+extern int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type);
 extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages);
 extern bool is_memblock_offlined(struct memory_block *mem);
 extern void remove_memory(int nid, u64 start, u64 size);
diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index 9341619..1f720f7 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -41,12 +41,14 @@ static inline struct vmem_altmap *to_vmem_altmap(unsigned long memmap_start)
  * @res: physical address range covered by @ref
  * @ref: reference count that pins the devm_memremap_pages() mapping
  * @dev: host device of the mapping for debug
+ * @type: memory type see MEMORY_* in memory_hotplug.h
  */
 struct dev_pagemap {
 	struct vmem_altmap *altmap;
 	const struct resource *res;
 	struct percpu_ref *ref;
 	struct device *dev;
+	enum memory_type type;
 };
 
 #ifdef CONFIG_ZONE_DEVICE
diff --git a/kernel/memremap.c b/kernel/memremap.c
index 07e85e5..6b4505d 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -248,7 +248,7 @@ static void devm_memremap_pages_release(struct device *dev, void *data)
 	align_size = ALIGN(resource_size(res), SECTION_SIZE);
 
 	mem_hotplug_begin();
-	arch_remove_memory(align_start, align_size);
+	arch_remove_memory(align_start, align_size, pgmap->type);
 	mem_hotplug_done();
 
 	untrack_pfn(NULL, PHYS_PFN(align_start), align_size);
@@ -326,6 +326,7 @@ void *devm_memremap_pages(struct device *dev, struct resource *res,
 	}
 	pgmap->ref = ref;
 	pgmap->res = &page_map->res;
+	pgmap->type = MEMORY_DEVICE_PERSISTENT;
 
 	mutex_lock(&pgmap_lock);
 	error = 0;
@@ -363,7 +364,7 @@ void *devm_memremap_pages(struct device *dev, struct resource *res,
 		goto err_pfn_remap;
 
 	mem_hotplug_begin();
-	error = arch_add_memory(nid, align_start, align_size, true);
+	error = arch_add_memory(nid, align_start, align_size, pgmap->type);
 	mem_hotplug_done();
 	if (error)
 		goto err_add_memory;
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index a07a07c..d1a4326 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1384,7 +1384,7 @@ int __ref add_memory_resource(int nid, struct resource *res, bool online)
 	}
 
 	/* call arch's memory hotadd */
-	ret = arch_add_memory(nid, start, size, false);
+	ret = arch_add_memory(nid, start, size, MEMORY_NORMAL);
 
 	if (ret < 0)
 		goto error;
@@ -2188,7 +2188,7 @@ void __ref remove_memory(int nid, u64 start, u64 size)
 	memblock_free(start, size);
 	memblock_remove(start, size);
 
-	arch_remove_memory(start, size);
+	arch_remove_memory(start, size, MEMORY_NORMAL);
 
 	try_offline_node(nid);
 
-- 
2.9.3

[toc] | [next] | [standalone]

#1617815 — Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 5f84433..0933261 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -126,14 +126,31 @@ int __weak remove_section_mapping(unsigned long start, unsigned long end)
>  	return -ENODEV;
>  }
>  
> -int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
> +int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
>  {
>  	struct pglist_data *pgdata;
> -	struct zone *zone;
>  	unsigned long start_pfn = start >> PAGE_SHIFT;
>  	unsigned long nr_pages = size >> PAGE_SHIFT;
> +	bool for_device = false;
> +	struct zone *zone;
>  	int rc;
>  
> +	/*
> +	 * Each memory_type needs special handling, so error out on an
> +	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
> +	 * is not supported on this architecture.

The concept of MEMORY_DEVICE_UNADDRESSABLE has not been
introduced yet in this patch if I read correctly.

[toc] | [prev] | [next] | [standalone]

#1618030 — Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

> > diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> > index 5f84433..0933261 100644
> > --- a/arch/powerpc/mm/mem.c
> > +++ b/arch/powerpc/mm/mem.c
> > @@ -126,14 +126,31 @@ int __weak remove_section_mapping(unsigned long
> > start, unsigned long end)
> >  	return -ENODEV;
> >  }
> >  
> > -int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
> > +int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
> >  {
> >  	struct pglist_data *pgdata;
> > -	struct zone *zone;
> >  	unsigned long start_pfn = start >> PAGE_SHIFT;
> >  	unsigned long nr_pages = size >> PAGE_SHIFT;
> > +	bool for_device = false;
> > +	struct zone *zone;
> >  	int rc;
> >  
> > +	/*
> > +	 * Each memory_type needs special handling, so error out on an
> > +	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
> > +	 * is not supported on this architecture.
> 
> The concept of MEMORY_DEVICE_UNADDRESSABLE has not been
> introduced yet in this patch if I read correctly.

Correct, i did not want to add comment to all the arch file in the patch
that add it because this is one of the most painful patch to rebase so
instead of having more patch that are problematic for rebase i just added
the proper comment ahead of time to make my constant rebasing easier.

Cheers,
Jérôme

[toc] | [prev] | [next] | [standalone]

#1618719 — Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

On Wed 05-04-17 16:40:11, Jérôme Glisse wrote:
> When hotpluging memory we want more information on the type of memory.
> This is to extend ZONE_DEVICE to support new type of memory other than
> the persistent memory. Existing user of ZONE_DEVICE (persistent memory)
> will be left un-modified.

My current hotplug rework [1] is touching this path as well. It is not
really clear from the chage why you are changing this and what are the
further expectations of MEMORY_DEVICE_PERSISTENT. Infact I have replaced
for_device with want__memblock [2]. I plan to repost shortly but I would
like to understand your modifications more to reduce potential conflicts
in the code. Why do you need to distinguish different types of memory
anyway.

[1] http://lkml.kernel.org/r/20170330115454.32154-1-mhocko@kernel.org
[2] the current patchset is in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
    branch attempts/rewrite-mem_hotplug-WIP
> 
> Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Rich Felker <dalias@libc.org>
> Cc: Chris Metcalf <cmetcalf@mellanox.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> ---
>  arch/ia64/mm/init.c            | 36 +++++++++++++++++++++++++++++++++---
>  arch/powerpc/mm/mem.c          | 37 ++++++++++++++++++++++++++++++++++---
>  arch/s390/mm/init.c            | 16 ++++++++++++++--
>  arch/sh/mm/init.c              | 35 +++++++++++++++++++++++++++++++++--
>  arch/x86/mm/init_32.c          | 41 +++++++++++++++++++++++++++++++++++++----
>  arch/x86/mm/init_64.c          | 39 +++++++++++++++++++++++++++++++++++----
>  include/linux/memory_hotplug.h | 24 ++++++++++++++++++++++--
>  include/linux/memremap.h       |  2 ++
>  kernel/memremap.c              |  5 +++--
>  mm/memory_hotplug.c            |  4 ++--
>  10 files changed, 215 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
> index 06cdaef..c910b3f 100644
> --- a/arch/ia64/mm/init.c
> +++ b/arch/ia64/mm/init.c
> @@ -645,20 +645,36 @@ mem_init (void)
>  }
>  
>  #ifdef CONFIG_MEMORY_HOTPLUG
> -int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
> +int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
>  {
>  	pg_data_t *pgdat;
>  	struct zone *zone;
>  	unsigned long start_pfn = start >> PAGE_SHIFT;
>  	unsigned long nr_pages = size >> PAGE_SHIFT;
> +	bool for_device = false;
>  	int ret;
>  
> +	/*
> +	 * Each memory_type needs special handling, so error out on an
> +	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
> +	 * is not supported on this architecture.
> +	 */
> +	switch (type) {
> +	case MEMORY_NORMAL:
> +		break;
> +	case MEMORY_DEVICE_PERSISTENT:
> +		for_device = true;
> +		break;
> +	default:
> +		pr_err("hotplug unsupported memory type %d\n", type);
> +		return -EINVAL;
> +	}
> +
>  	pgdat = NODE_DATA(nid);
>  
>  	zone = pgdat->node_zones +
>  		zone_for_memory(nid, start, size, ZONE_NORMAL, for_device);
>  	ret = __add_pages(nid, zone, start_pfn, nr_pages);
> -
>  	if (ret)
>  		printk("%s: Problem encountered in __add_pages() as ret=%d\n",
>  		       __func__,  ret);
> @@ -667,13 +683,27 @@ int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
>  }
>  
>  #ifdef CONFIG_MEMORY_HOTREMOVE
> -int arch_remove_memory(u64 start, u64 size)
> +int arch_remove_memory(u64 start, u64 size, enum memory_type type)
>  {
>  	unsigned long start_pfn = start >> PAGE_SHIFT;
>  	unsigned long nr_pages = size >> PAGE_SHIFT;
>  	struct zone *zone;
>  	int ret;
>  
> +	/*
> +	 * Each memory_type needs special handling, so error out on an
> +	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
> +	 * is not supported on this architecture.
> +	 */
> +	switch (type) {
> +	case MEMORY_NORMAL:
> +	case MEMORY_DEVICE_PERSISTENT:
> +		break;
> +	default:
> +		pr_err("hotplug unsupported memory type %d\n", type);
> +		return -EINVAL;
> +	}
> +
>  	zone = page_zone(pfn_to_page(start_pfn));
>  	ret = __remove_pages(zone, start_pfn, nr_pages);
>  	if (ret)
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 5f84433..0933261 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -126,14 +126,31 @@ int __weak remove_section_mapping(unsigned long start, unsigned long end)
>  	return -ENODEV;
>  }
>  
> -int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
> +int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
>  {
>  	struct pglist_data *pgdata;
> -	struct zone *zone;
>  	unsigned long start_pfn = start >> PAGE_SHIFT;
>  	unsigned long nr_pages = size >> PAGE_SHIFT;
> +	bool for_device = false;
> +	struct zone *zone;
>  	int rc;
>  
> +	/*
> +	 * Each memory_type needs special handling, so error out on an
> +	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
> +	 * is not supported on this architecture.
> +	 */
> +	switch (type) {
> +	case MEMORY_NORMAL:
> +		break;
> +	case MEMORY_DEVICE_PERSISTENT:
> +		for_device = true;
> +		break;
> +	default:
> +		pr_err("hotplug unsupported memory type %d\n", type);
> +		return -EINVAL;
> +	}
> +
>  	pgdata = NODE_DATA(nid);
>  
>  	start = (unsigned long)__va(start);
> @@ -153,13 +170,27 @@ int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
>  }
>  
>  #ifdef CONFIG_MEMORY_HOTREMOVE
> -int arch_remove_memory(u64 start, u64 size)
> +int arch_remove_memory(u64 start, u64 size, enum memory_type type)
>  {
>  	unsigned long start_pfn = start >> PAGE_SHIFT;
>  	unsigned long nr_pages = size >> PAGE_SHIFT;
>  	struct zone *zone;
>  	int ret;
>  
> +	/*
> +	 * Each memory_type needs special handling, so error out on an
> +	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
> +	 * is not supported on this architecture.
> +	 */
> +	switch (type) {
> +	case MEMORY_NORMAL:
> +	case MEMORY_DEVICE_PERSISTENT:
> +		break;
> +	default:
> +		pr_err("hotplug unsupported memory type %d\n", type);
> +		return -EINVAL;
> +	}
> +
>  	zone = page_zone(pfn_to_page(start_pfn));
>  	ret = __remove_pages(zone, start_pfn, nr_pages);
>  	if (ret)
> diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
> index bf5b8a0..20d7714 100644
> --- a/arch/s390/mm/init.c
> +++ b/arch/s390/mm/init.c
> @@ -153,7 +153,7 @@ void __init free_initrd_mem(unsigned long start, unsigned long end)
>  #endif
>  
>  #ifdef CONFIG_MEMORY_HOTPLUG
> -int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
> +int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
>  {
>  	unsigned long zone_start_pfn, zone_end_pfn, nr_pages;
>  	unsigned long start_pfn = PFN_DOWN(start);
> @@ -162,6 +162,18 @@ int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
>  	struct zone *zone;
>  	int rc, i;
>  
> +	/*
> +	 * Each memory_type needs special handling, so error out on an
> +	 * unsupported type.
> +	 */
> +	switch (type) {
> +	case MEMORY_NORMAL:
> +		break;
> +	default:
> +		pr_err("hotplug unsupported memory type %d\n", type);
> +		return -EINVAL;
> +	}
> +
>  	rc = vmem_add_mapping(start, size);
>  	if (rc)
>  		return rc;
> @@ -205,7 +217,7 @@ unsigned long memory_block_size_bytes(void)
>  }
>  
>  #ifdef CONFIG_MEMORY_HOTREMOVE
> -int arch_remove_memory(u64 start, u64 size)
> +int arch_remove_memory(u64 start, u64 size, enum memory_type type)
>  {
>  	/*
>  	 * There is no hardware or firmware interface which could trigger a
> diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
> index 7549186..f37e7a6 100644
> --- a/arch/sh/mm/init.c
> +++ b/arch/sh/mm/init.c
> @@ -485,13 +485,30 @@ void free_initrd_mem(unsigned long start, unsigned long end)
>  #endif
>  
>  #ifdef CONFIG_MEMORY_HOTPLUG
> -int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
> +int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
>  {
>  	pg_data_t *pgdat;
>  	unsigned long start_pfn = PFN_DOWN(start);
>  	unsigned long nr_pages = size >> PAGE_SHIFT;
> +	bool for_device = false;
>  	int ret;
>  
> +	/*
> +	 * Each memory_type needs special handling, so error out on an
> +	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
> +	 * is not supported on this architecture.
> +	 */
> +	switch (type) {
> +	case MEMORY_NORMAL:
> +		break;
> +	case MEMORY_DEVICE_PERSISTENT:
> +		for_device = true;
> +		break;
> +	default:
> +		pr_err("hotplug unsupported memory type %d\n", type);
> +		return -EINVAL;
> +	}
> +
>  	pgdat = NODE_DATA(nid);
>  
>  	/* We only have ZONE_NORMAL, so this is easy.. */
> @@ -516,13 +533,27 @@ EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
>  #endif
>  
>  #ifdef CONFIG_MEMORY_HOTREMOVE
> -int arch_remove_memory(u64 start, u64 size)
> +int arch_remove_memory(u64 start, u64 size, enum memory_type type)
>  {
>  	unsigned long start_pfn = PFN_DOWN(start);
>  	unsigned long nr_pages = size >> PAGE_SHIFT;
>  	struct zone *zone;
>  	int ret;
>  
> +	/*
> +	 * Each memory_type needs special handling, so error out on an
> +	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
> +	 * is not supported on this architecture.
> +	 */
> +	switch (type) {
> +	case MEMORY_NORMAL:
> +	case MEMORY_DEVICE_PERSISTENT:
> +		break;
> +	default:
> +		pr_err("hotplug unsupported memory type %d\n", type);
> +		return -EINVAL;
> +	}
> +
>  	zone = page_zone(pfn_to_page(start_pfn));
>  	ret = __remove_pages(zone, start_pfn, nr_pages);
>  	if (unlikely(ret))
> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> index c68078f..811d631 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -826,24 +826,57 @@ void __init mem_init(void)
>  }
>  
>  #ifdef CONFIG_MEMORY_HOTPLUG
> -int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
> +int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
>  {
>  	struct pglist_data *pgdata = NODE_DATA(nid);
> -	struct zone *zone = pgdata->node_zones +
> -		zone_for_memory(nid, start, size, ZONE_HIGHMEM, for_device);
>  	unsigned long start_pfn = start >> PAGE_SHIFT;
>  	unsigned long nr_pages = size >> PAGE_SHIFT;
> +	bool for_device = false;
> +	struct zone *zone;
> +
> +	/*
> +	 * Each memory_type needs special handling, so error out on an
> +	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
> +	 * is not supported on this architecture.
> +	 */
> +	switch (type) {
> +	case MEMORY_NORMAL:
> +		break;
> +	case MEMORY_DEVICE_PERSISTENT:
> +		for_device = true;
> +		break;
> +	default:
> +		pr_err("hotplug unsupported memory type %d\n", type);
> +		return -EINVAL;
> +	}
> +
> +	zone = pgdata->node_zones +
> +		zone_for_memory(nid, start, size, ZONE_HIGHMEM, for_device);
>  
>  	return __add_pages(nid, zone, start_pfn, nr_pages);
>  }
>  
>  #ifdef CONFIG_MEMORY_HOTREMOVE
> -int arch_remove_memory(u64 start, u64 size)
> +int arch_remove_memory(u64 start, u64 size, enum memory_type type)
>  {
>  	unsigned long start_pfn = start >> PAGE_SHIFT;
>  	unsigned long nr_pages = size >> PAGE_SHIFT;
>  	struct zone *zone;
>  
> +	/*
> +	 * Each memory_type needs special handling, so error out on an
> +	 * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
> +	 * is not supported on this architecture.
> +	 */
> +	switch (type) {
> +	case MEMORY_NORMAL:
> +	case MEMORY_DEVICE_PERSISTENT:
> +		break;
> +	default:
> +		pr_err("hotplug unsupported memory type %d\n", type);
> +		return -EINVAL;
> +	}
> +
>  	zone = page_zone(pfn_to_page(start_pfn));
>  	return __remove_pages(zone, start_pfn, nr_pages);
>  }
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 7eef172..6c0b24e 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -641,15 +641,33 @@ static void  update_end_of_memory_vars(u64 start, u64 size)
>   * Memory is added always to NORMAL zone. This means you will never get
>   * additional DMA/DMA32 memory.
>   */
> -int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
> +int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
>  {
>  	struct pglist_data *pgdat = NODE_DATA(nid);
> -	struct zone *zone = pgdat->node_zones +
> -		zone_for_memory(nid, start, size, ZONE_NORMAL, for_device);
>  	unsigned long start_pfn = start >> PAGE_SHIFT;
>  	unsigned long nr_pages = size >> PAGE_SHIFT;
> +	bool for_device = false;
> +	struct zone *zone;
>  	int ret;
>  
> +	/*
> +	 * Each memory_type needs special handling, so error out on an
> +	 * unsupported type.
> +	 */
> +	switch (type) {
> +	case MEMORY_NORMAL:
> +		break;
> +	case MEMORY_DEVICE_PERSISTENT:
> +		for_device = true;
> +		break;
> +	default:
> +		pr_err("hotplug unsupported memory type %d\n", type);
> +		return -EINVAL;
> +	}
> +
> +	zone = pgdat->node_zones +
> +		zone_for_memory(nid, start, size, ZONE_NORMAL, for_device);
> +
>  	init_memory_mapping(start, start + size);
>  
>  	ret = __add_pages(nid, zone, start_pfn, nr_pages);
> @@ -946,7 +964,7 @@ kernel_physical_mapping_remove(unsigned long start, unsigned long end)
>  	remove_pagetable(start, end, true);
>  }
>  
> -int __ref arch_remove_memory(u64 start, u64 size)
> +int __ref arch_remove_memory(u64 start, u64 size, enum memory_type type)
>  {
>  	unsigned long start_pfn = start >> PAGE_SHIFT;
>  	unsigned long nr_pages = size >> PAGE_SHIFT;
> @@ -955,6 +973,19 @@ int __ref arch_remove_memory(u64 start, u64 size)
>  	struct zone *zone;
>  	int ret;
>  
> +	/*
> +	 * Each memory_type needs special handling, so error out on an
> +	 * unsupported type.
> +	 */
> +	switch (type) {
> +	case MEMORY_NORMAL:
> +	case MEMORY_DEVICE_PERSISTENT:
> +		break;
> +	default:
> +		pr_err("hotplug unsupported memory type %d\n", type);
> +		return -EINVAL;
> +	}
> +
>  	/* With altmap the first mapped page is offset from @start */
>  	altmap = to_vmem_altmap((unsigned long) page);
>  	if (altmap)
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 134a2f6..c3999f2 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -13,6 +13,26 @@ struct mem_section;
>  struct memory_block;
>  struct resource;
>  
> +/*
> + * When hotplugging memory with arch_add_memory(), we want more information on
> + * the type of memory we are hotplugging, because depending on the type of
> + * architecture, the code might want to take different paths.
> + *
> + * MEMORY_NORMAL:
> + * Your regular system memory. Default common case.
> + *
> + * MEMORY_DEVICE_PERSISTENT:
> + * Persistent device memory (pmem): struct page might be allocated in different
> + * memory and architecture might want to perform special actions. It is similar
> + * to regular memory, in that the CPU can access it transparently. However,
> + * it is likely to have different bandwidth and latency than regular memory.
> + * See Documentation/nvdimm/nvdimm.txt for more information.
> + */
> +enum memory_type {
> +	MEMORY_NORMAL = 0,
> +	MEMORY_DEVICE_PERSISTENT,
> +};
> +
>  #ifdef CONFIG_MEMORY_HOTPLUG
>  
>  /*
> @@ -104,7 +124,7 @@ extern bool memhp_auto_online;
>  
>  #ifdef CONFIG_MEMORY_HOTREMOVE
>  extern bool is_pageblock_removable_nolock(struct page *page);
> -extern int arch_remove_memory(u64 start, u64 size);
> +extern int arch_remove_memory(u64 start, u64 size, enum memory_type type);
>  extern int __remove_pages(struct zone *zone, unsigned long start_pfn,
>  	unsigned long nr_pages);
>  #endif /* CONFIG_MEMORY_HOTREMOVE */
> @@ -276,7 +296,7 @@ extern int add_memory(int nid, u64 start, u64 size);
>  extern int add_memory_resource(int nid, struct resource *resource, bool online);
>  extern int zone_for_memory(int nid, u64 start, u64 size, int zone_default,
>  		bool for_device);
> -extern int arch_add_memory(int nid, u64 start, u64 size, bool for_device);
> +extern int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type);
>  extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages);
>  extern bool is_memblock_offlined(struct memory_block *mem);
>  extern void remove_memory(int nid, u64 start, u64 size);
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 9341619..1f720f7 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -41,12 +41,14 @@ static inline struct vmem_altmap *to_vmem_altmap(unsigned long memmap_start)
>   * @res: physical address range covered by @ref
>   * @ref: reference count that pins the devm_memremap_pages() mapping
>   * @dev: host device of the mapping for debug
> + * @type: memory type see MEMORY_* in memory_hotplug.h
>   */
>  struct dev_pagemap {
>  	struct vmem_altmap *altmap;
>  	const struct resource *res;
>  	struct percpu_ref *ref;
>  	struct device *dev;
> +	enum memory_type type;
>  };
>  
>  #ifdef CONFIG_ZONE_DEVICE
> diff --git a/kernel/memremap.c b/kernel/memremap.c
> index 07e85e5..6b4505d 100644
> --- a/kernel/memremap.c
> +++ b/kernel/memremap.c
> @@ -248,7 +248,7 @@ static void devm_memremap_pages_release(struct device *dev, void *data)
>  	align_size = ALIGN(resource_size(res), SECTION_SIZE);
>  
>  	mem_hotplug_begin();
> -	arch_remove_memory(align_start, align_size);
> +	arch_remove_memory(align_start, align_size, pgmap->type);
>  	mem_hotplug_done();
>  
>  	untrack_pfn(NULL, PHYS_PFN(align_start), align_size);
> @@ -326,6 +326,7 @@ void *devm_memremap_pages(struct device *dev, struct resource *res,
>  	}
>  	pgmap->ref = ref;
>  	pgmap->res = &page_map->res;
> +	pgmap->type = MEMORY_DEVICE_PERSISTENT;
>  
>  	mutex_lock(&pgmap_lock);
>  	error = 0;
> @@ -363,7 +364,7 @@ void *devm_memremap_pages(struct device *dev, struct resource *res,
>  		goto err_pfn_remap;
>  
>  	mem_hotplug_begin();
> -	error = arch_add_memory(nid, align_start, align_size, true);
> +	error = arch_add_memory(nid, align_start, align_size, pgmap->type);
>  	mem_hotplug_done();
>  	if (error)
>  		goto err_add_memory;
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index a07a07c..d1a4326 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1384,7 +1384,7 @@ int __ref add_memory_resource(int nid, struct resource *res, bool online)
>  	}
>  
>  	/* call arch's memory hotadd */
> -	ret = arch_add_memory(nid, start, size, false);
> +	ret = arch_add_memory(nid, start, size, MEMORY_NORMAL);
>  
>  	if (ret < 0)
>  		goto error;
> @@ -2188,7 +2188,7 @@ void __ref remove_memory(int nid, u64 start, u64 size)
>  	memblock_free(start, size);
>  	memblock_remove(start, size);
>  
> -	arch_remove_memory(start, size);
> +	arch_remove_memory(start, size, MEMORY_NORMAL);
>  
>  	try_offline_node(nid);
>  
> -- 
> 2.9.3
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1618857 — Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

On Fri, Apr 07, 2017 at 02:13:49PM +0200, Michal Hocko wrote:
> On Wed 05-04-17 16:40:11, Jérôme Glisse wrote:
> > When hotpluging memory we want more information on the type of memory.
> > This is to extend ZONE_DEVICE to support new type of memory other than
> > the persistent memory. Existing user of ZONE_DEVICE (persistent memory)
> > will be left un-modified.
> 
> My current hotplug rework [1] is touching this path as well. It is not
> really clear from the chage why you are changing this and what are the
> further expectations of MEMORY_DEVICE_PERSISTENT. Infact I have replaced
> for_device with want__memblock [2]. I plan to repost shortly but I would
> like to understand your modifications more to reduce potential conflicts
> in the code. Why do you need to distinguish different types of memory
> anyway.
> 
> [1] http://lkml.kernel.org/r/20170330115454.32154-1-mhocko@kernel.org
> [2] the current patchset is in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>     branch attempts/rewrite-mem_hotplug-WIP

This is needed for UNADDRESSABLE memory type introduced in patch 3 and
the arch specific bits are in patch 4. Basicly for UNADDRESSABLE memory
i do not want the arch code to create a linear mapping for the range
being hotpluged. Adding memory_type in this patch allow to distinguish
between different type of ZONE_DEVICE.

After your patchset, we do not need the for_device but i still need to
know if it is UNADDRESSABLE. You can check my branch on top of your
previous patchset (again patch 1, 3 and 4):

https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-v20

1:
https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-v20&id=a85a895615e4812d3c68869cfeef92a4924b4946
3:
https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-v20&id=539b6d12429a7166f3690944d6bf164930a59def
4:
https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-v20&id=d5338b868e801acabb96c7166c1e802d730511e3

I will check your new branch and see what want_memblock is for.

Cheers,
Jérôme

[toc] | [prev] | [next] | [standalone]

#1618867 — Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

On Fri 07-04-17 10:32:49, Jerome Glisse wrote:
> On Fri, Apr 07, 2017 at 02:13:49PM +0200, Michal Hocko wrote:
> > On Wed 05-04-17 16:40:11, Jérôme Glisse wrote:
> > > When hotpluging memory we want more information on the type of memory.
> > > This is to extend ZONE_DEVICE to support new type of memory other than
> > > the persistent memory. Existing user of ZONE_DEVICE (persistent memory)
> > > will be left un-modified.
> > 
> > My current hotplug rework [1] is touching this path as well. It is not
> > really clear from the chage why you are changing this and what are the
> > further expectations of MEMORY_DEVICE_PERSISTENT. Infact I have replaced
> > for_device with want__memblock [2]. I plan to repost shortly but I would
> > like to understand your modifications more to reduce potential conflicts
> > in the code. Why do you need to distinguish different types of memory
> > anyway.
> > 
> > [1] http://lkml.kernel.org/r/20170330115454.32154-1-mhocko@kernel.org
> > [2] the current patchset is in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> >     branch attempts/rewrite-mem_hotplug-WIP
> 
> This is needed for UNADDRESSABLE memory type introduced in patch 3 and
> the arch specific bits are in patch 4. Basicly for UNADDRESSABLE memory
> i do not want the arch code to create a linear mapping for the range
> being hotpluged. Adding memory_type in this patch allow to distinguish
> between different type of ZONE_DEVICE.

Why don't you use __add_pages directly then?
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1618879 — Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

On Fri, Apr 07, 2017 at 04:45:04PM +0200, Michal Hocko wrote:
> On Fri 07-04-17 10:32:49, Jerome Glisse wrote:
> > On Fri, Apr 07, 2017 at 02:13:49PM +0200, Michal Hocko wrote:
> > > On Wed 05-04-17 16:40:11, Jérôme Glisse wrote:
> > > > When hotpluging memory we want more information on the type of memory.
> > > > This is to extend ZONE_DEVICE to support new type of memory other than
> > > > the persistent memory. Existing user of ZONE_DEVICE (persistent memory)
> > > > will be left un-modified.
> > > 
> > > My current hotplug rework [1] is touching this path as well. It is not
> > > really clear from the chage why you are changing this and what are the
> > > further expectations of MEMORY_DEVICE_PERSISTENT. Infact I have replaced
> > > for_device with want__memblock [2]. I plan to repost shortly but I would
> > > like to understand your modifications more to reduce potential conflicts
> > > in the code. Why do you need to distinguish different types of memory
> > > anyway.
> > > 
> > > [1] http://lkml.kernel.org/r/20170330115454.32154-1-mhocko@kernel.org
> > > [2] the current patchset is in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> > >     branch attempts/rewrite-mem_hotplug-WIP
> > 
> > This is needed for UNADDRESSABLE memory type introduced in patch 3 and
> > the arch specific bits are in patch 4. Basicly for UNADDRESSABLE memory
> > i do not want the arch code to create a linear mapping for the range
> > being hotpluged. Adding memory_type in this patch allow to distinguish
> > between different type of ZONE_DEVICE.
> 
> Why don't you use __add_pages directly then?

That's a possibility, i wanted to keep the arch code in the loop in case
some arch wanted to do something specific. But it is unlikely to ever be
use outside x86 and i don't think we will want to do anything more than
skipping linear mapping.

Note that however for CDM when doing it with ZONE_DEVICE (i am gonna
post an RFC for that) maybe the powerpc folks will want to know the
memory type ie what kind of ZONE_DEVICE this is. I don't think they need
it but i am not sure if there is anything specific needed for their
next gen power 9 in respect of device memory.


Andrew if Michal think it is better to not use arch_add_memory directly
for my case than i can respin HMM patchset. Let me know.

(Patch 1 and 4 would be drop, patch 3 and 14 would need updates from
top of my head).

Cheers,
Jérôme

[toc] | [prev] | [next] | [standalone]

#1618892 — Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

On Fri 07-04-17 10:57:43, Jerome Glisse wrote:
> On Fri, Apr 07, 2017 at 04:45:04PM +0200, Michal Hocko wrote:
> > On Fri 07-04-17 10:32:49, Jerome Glisse wrote:
> > > On Fri, Apr 07, 2017 at 02:13:49PM +0200, Michal Hocko wrote:
> > > > On Wed 05-04-17 16:40:11, Jérôme Glisse wrote:
> > > > > When hotpluging memory we want more information on the type of memory.
> > > > > This is to extend ZONE_DEVICE to support new type of memory other than
> > > > > the persistent memory. Existing user of ZONE_DEVICE (persistent memory)
> > > > > will be left un-modified.
> > > > 
> > > > My current hotplug rework [1] is touching this path as well. It is not
> > > > really clear from the chage why you are changing this and what are the
> > > > further expectations of MEMORY_DEVICE_PERSISTENT. Infact I have replaced
> > > > for_device with want__memblock [2]. I plan to repost shortly but I would
> > > > like to understand your modifications more to reduce potential conflicts
> > > > in the code. Why do you need to distinguish different types of memory
> > > > anyway.
> > > > 
> > > > [1] http://lkml.kernel.org/r/20170330115454.32154-1-mhocko@kernel.org
> > > > [2] the current patchset is in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> > > >     branch attempts/rewrite-mem_hotplug-WIP
> > > 
> > > This is needed for UNADDRESSABLE memory type introduced in patch 3 and
> > > the arch specific bits are in patch 4. Basicly for UNADDRESSABLE memory
> > > i do not want the arch code to create a linear mapping for the range
> > > being hotpluged. Adding memory_type in this patch allow to distinguish
> > > between different type of ZONE_DEVICE.
> > 
> > Why don't you use __add_pages directly then?
> 
> That's a possibility, i wanted to keep the arch code in the loop in case
> some arch wanted to do something specific. But it is unlikely to ever be
> use outside x86 and i don't think we will want to do anything more than
> skipping linear mapping.

Hmm, I am looking closer and x86 stil updates max_pfn. Is this needed
or you are guaranteed to not cross the max_pfn?
 
> Note that however for CDM when doing it with ZONE_DEVICE (i am gonna
> post an RFC for that) maybe the powerpc folks will want to know the
> memory type ie what kind of ZONE_DEVICE this is. I don't think they need
> it but i am not sure if there is anything specific needed for their
> next gen power 9 in respect of device memory.

Well, I really want to get rid of anything zone specific down the
arch_add_memory. So whatever they want to do with zone they will have to
do it after arch_add_memory.

> Andrew if Michal think it is better to not use arch_add_memory directly
> for my case than i can respin HMM patchset. Let me know.

Well, I can drop
https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git/commit/?h=attempts/rewrite-mem_hotplug-WIP&id=bb1657d823a85bca045712467f517980650652ca
and arch_add_memory can have memory type argument as you suggest. I am
just trying to understand what are the expectations here. If you only care
about x86 then it sounds a bit too much to tweak all arches.
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1618936 — Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

On Fri, Apr 07, 2017 at 05:11:05PM +0200, Michal Hocko wrote:
> On Fri 07-04-17 10:57:43, Jerome Glisse wrote:
> > On Fri, Apr 07, 2017 at 04:45:04PM +0200, Michal Hocko wrote:
> > > On Fri 07-04-17 10:32:49, Jerome Glisse wrote:
> > > > On Fri, Apr 07, 2017 at 02:13:49PM +0200, Michal Hocko wrote:
> > > > > On Wed 05-04-17 16:40:11, Jérôme Glisse wrote:
> > > > > > When hotpluging memory we want more information on the type of memory.
> > > > > > This is to extend ZONE_DEVICE to support new type of memory other than
> > > > > > the persistent memory. Existing user of ZONE_DEVICE (persistent memory)
> > > > > > will be left un-modified.
> > > > > 
> > > > > My current hotplug rework [1] is touching this path as well. It is not
> > > > > really clear from the chage why you are changing this and what are the
> > > > > further expectations of MEMORY_DEVICE_PERSISTENT. Infact I have replaced
> > > > > for_device with want__memblock [2]. I plan to repost shortly but I would
> > > > > like to understand your modifications more to reduce potential conflicts
> > > > > in the code. Why do you need to distinguish different types of memory
> > > > > anyway.
> > > > > 
> > > > > [1] http://lkml.kernel.org/r/20170330115454.32154-1-mhocko@kernel.org
> > > > > [2] the current patchset is in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> > > > >     branch attempts/rewrite-mem_hotplug-WIP
> > > > 
> > > > This is needed for UNADDRESSABLE memory type introduced in patch 3 and
> > > > the arch specific bits are in patch 4. Basicly for UNADDRESSABLE memory
> > > > i do not want the arch code to create a linear mapping for the range
> > > > being hotpluged. Adding memory_type in this patch allow to distinguish
> > > > between different type of ZONE_DEVICE.
> > > 
> > > Why don't you use __add_pages directly then?
> > 
> > That's a possibility, i wanted to keep the arch code in the loop in case
> > some arch wanted to do something specific. But it is unlikely to ever be
> > use outside x86 and i don't think we will want to do anything more than
> > skipping linear mapping.
> 
> Hmm, I am looking closer and x86 stil updates max_pfn. Is this needed
> or you are guaranteed to not cross the max_pfn?

No guaranteed so yes i somewhat care about max_pfn, i do not care about
any of its existing user last time i check but it might matter for some
new user.

>  
> > Note that however for CDM when doing it with ZONE_DEVICE (i am gonna
> > post an RFC for that) maybe the powerpc folks will want to know the
> > memory type ie what kind of ZONE_DEVICE this is. I don't think they need
> > it but i am not sure if there is anything specific needed for their
> > next gen power 9 in respect of device memory.
> 
> Well, I really want to get rid of anything zone specific down the
> arch_add_memory. So whatever they want to do with zone they will have to
> do it after arch_add_memory.

I am ok with that except that the linear mapping thing is in arch_add_memory
and this is the thing i want to skip.

> 
> > Andrew if Michal think it is better to not use arch_add_memory directly
> > for my case than i can respin HMM patchset. Let me know.
> 
> Well, I can drop
> https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git/commit/?h=attempts/rewrite-mem_hotplug-WIP&id=bb1657d823a85bca045712467f517980650652ca
> and arch_add_memory can have memory type argument as you suggest. I am
> just trying to understand what are the expectations here. If you only care
> about x86 then it sounds a bit too much to tweak all arches.

Well i care about powerpc and i know some arm folks are interested in HMM
but it is hard to know when this will materialize. So long run i expect
more arch but it might not happen soon.

Cheers,
Jérôme

[toc] | [prev] | [next] | [standalone]

#1618955 — Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

On Fri 07-04-17 12:10:00, Jerome Glisse wrote:
> On Fri, Apr 07, 2017 at 05:11:05PM +0200, Michal Hocko wrote:
> > On Fri 07-04-17 10:57:43, Jerome Glisse wrote:
> > > On Fri, Apr 07, 2017 at 04:45:04PM +0200, Michal Hocko wrote:
> > > > On Fri 07-04-17 10:32:49, Jerome Glisse wrote:
> > > > > On Fri, Apr 07, 2017 at 02:13:49PM +0200, Michal Hocko wrote:
> > > > > > On Wed 05-04-17 16:40:11, Jérôme Glisse wrote:
> > > > > > > When hotpluging memory we want more information on the type of memory.
> > > > > > > This is to extend ZONE_DEVICE to support new type of memory other than
> > > > > > > the persistent memory. Existing user of ZONE_DEVICE (persistent memory)
> > > > > > > will be left un-modified.
> > > > > > 
> > > > > > My current hotplug rework [1] is touching this path as well. It is not
> > > > > > really clear from the chage why you are changing this and what are the
> > > > > > further expectations of MEMORY_DEVICE_PERSISTENT. Infact I have replaced
> > > > > > for_device with want__memblock [2]. I plan to repost shortly but I would
> > > > > > like to understand your modifications more to reduce potential conflicts
> > > > > > in the code. Why do you need to distinguish different types of memory
> > > > > > anyway.
> > > > > > 
> > > > > > [1] http://lkml.kernel.org/r/20170330115454.32154-1-mhocko@kernel.org
> > > > > > [2] the current patchset is in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> > > > > >     branch attempts/rewrite-mem_hotplug-WIP
> > > > > 
> > > > > This is needed for UNADDRESSABLE memory type introduced in patch 3 and
> > > > > the arch specific bits are in patch 4. Basicly for UNADDRESSABLE memory
> > > > > i do not want the arch code to create a linear mapping for the range
> > > > > being hotpluged. Adding memory_type in this patch allow to distinguish
> > > > > between different type of ZONE_DEVICE.
> > > > 
> > > > Why don't you use __add_pages directly then?
> > > 
> > > That's a possibility, i wanted to keep the arch code in the loop in case
> > > some arch wanted to do something specific. But it is unlikely to ever be
> > > use outside x86 and i don't think we will want to do anything more than
> > > skipping linear mapping.
> > 
> > Hmm, I am looking closer and x86 stil updates max_pfn. Is this needed
> > or you are guaranteed to not cross the max_pfn?
> 
> No guaranteed so yes i somewhat care about max_pfn, i do not care about
> any of its existing user last time i check but it might matter for some
> new user.

OK, then we can add add_pages() which would do __add_pages by default
(#ifndef ARCH_HAS_ADD_PAGES) and x86 would override it do also call
update_end_of_memory_vars. This sounds easier to me than updating all
the archs and add something that most of them do not really care about.

But I will not insist. If you think that your approach is better I will
not object.

Btw. is your series reviewed and ready to be applied to the mm tree? I
planed to post mine on Monday so I would like to know how do we
coordinate. I rebase on topo of yours or vice versa.

Thanks!
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1618982 — Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

[Multipart message — attachments visible in raw view] — view raw

On Fri, Apr 07, 2017 at 06:37:37PM +0200, Michal Hocko wrote:
> On Fri 07-04-17 12:10:00, Jerome Glisse wrote:
> > On Fri, Apr 07, 2017 at 05:11:05PM +0200, Michal Hocko wrote:
> > > On Fri 07-04-17 10:57:43, Jerome Glisse wrote:
> > > > On Fri, Apr 07, 2017 at 04:45:04PM +0200, Michal Hocko wrote:
> > > > > On Fri 07-04-17 10:32:49, Jerome Glisse wrote:
> > > > > > On Fri, Apr 07, 2017 at 02:13:49PM +0200, Michal Hocko wrote:
> > > > > > > On Wed 05-04-17 16:40:11, Jérôme Glisse wrote:
> > > > > > > > When hotpluging memory we want more information on the type of memory.
> > > > > > > > This is to extend ZONE_DEVICE to support new type of memory other than
> > > > > > > > the persistent memory. Existing user of ZONE_DEVICE (persistent memory)
> > > > > > > > will be left un-modified.
> > > > > > > 
> > > > > > > My current hotplug rework [1] is touching this path as well. It is not
> > > > > > > really clear from the chage why you are changing this and what are the
> > > > > > > further expectations of MEMORY_DEVICE_PERSISTENT. Infact I have replaced
> > > > > > > for_device with want__memblock [2]. I plan to repost shortly but I would
> > > > > > > like to understand your modifications more to reduce potential conflicts
> > > > > > > in the code. Why do you need to distinguish different types of memory
> > > > > > > anyway.
> > > > > > > 
> > > > > > > [1] http://lkml.kernel.org/r/20170330115454.32154-1-mhocko@kernel.org
> > > > > > > [2] the current patchset is in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> > > > > > >     branch attempts/rewrite-mem_hotplug-WIP
> > > > > > 
> > > > > > This is needed for UNADDRESSABLE memory type introduced in patch 3 and
> > > > > > the arch specific bits are in patch 4. Basicly for UNADDRESSABLE memory
> > > > > > i do not want the arch code to create a linear mapping for the range
> > > > > > being hotpluged. Adding memory_type in this patch allow to distinguish
> > > > > > between different type of ZONE_DEVICE.
> > > > > 
> > > > > Why don't you use __add_pages directly then?
> > > > 
> > > > That's a possibility, i wanted to keep the arch code in the loop in case
> > > > some arch wanted to do something specific. But it is unlikely to ever be
> > > > use outside x86 and i don't think we will want to do anything more than
> > > > skipping linear mapping.
> > > 
> > > Hmm, I am looking closer and x86 stil updates max_pfn. Is this needed
> > > or you are guaranteed to not cross the max_pfn?
> > 
> > No guaranteed so yes i somewhat care about max_pfn, i do not care about
> > any of its existing user last time i check but it might matter for some
> > new user.
> 
> OK, then we can add add_pages() which would do __add_pages by default
> (#ifndef ARCH_HAS_ADD_PAGES) and x86 would override it do also call
> update_end_of_memory_vars. This sounds easier to me than updating all
> the archs and add something that most of them do not really care about.
> 
> But I will not insist. If you think that your approach is better I will
> not object.

Something like attached patch ?

> 
> Btw. is your series reviewed and ready to be applied to the mm tree? I
> planed to post mine on Monday so I would like to know how do we
> coordinate. I rebase on topo of yours or vice versa.

Well v18 core patches were review by Mel, i did include all of his comment
in v19 (i don't think i did miss any). I think Dan still want to look at
patch 1 and 3 for ZONE_DEVICE.

But i always welcome more review. I know Anshuman replied to this patch
to improve a comments. Balbir had issue on powerpc because iomem_resource.end
isn't clamped to MAX_PHYSMEM_BITS But that is all review i got so far on v19.

I don't mind rebasing on top of your patchset. What ever is easier for
Andrew i guess.

Cheers,
Jérôme

[toc] | [prev] | [next] | [standalone]

#1619010 — Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

On Fri 07-04-17 13:10:59, Jerome Glisse wrote:
> On Fri, Apr 07, 2017 at 06:37:37PM +0200, Michal Hocko wrote:
> > On Fri 07-04-17 12:10:00, Jerome Glisse wrote:
[...]
> > > No guaranteed so yes i somewhat care about max_pfn, i do not care about
> > > any of its existing user last time i check but it might matter for some
> > > new user.
> > 
> > OK, then we can add add_pages() which would do __add_pages by default
> > (#ifndef ARCH_HAS_ADD_PAGES) and x86 would override it do also call
> > update_end_of_memory_vars. This sounds easier to me than updating all
> > the archs and add something that most of them do not really care about.
> > 
> > But I will not insist. If you think that your approach is better I will
> > not object.
> 
> Something like attached patch ?

No I meant something like the diff below but maybe even that is too
excessive.
 
> > 
> > Btw. is your series reviewed and ready to be applied to the mm tree? I
> > planed to post mine on Monday so I would like to know how do we
> > coordinate. I rebase on topo of yours or vice versa.
> 
> Well v18 core patches were review by Mel, i did include all of his comment
> in v19 (i don't think i did miss any). I think Dan still want to look at
> patch 1 and 3 for ZONE_DEVICE.
> 
> But i always welcome more review. I know Anshuman replied to this patch
> to improve a comments. Balbir had issue on powerpc because iomem_resource.end
> isn't clamped to MAX_PHYSMEM_BITS But that is all review i got so far on v19.
> 
> I don't mind rebasing on top of your patchset. What ever is easier for
> Andrew i guess.

Well, considering that my patchset is changing the behavior of the core
of the memory hotplug I would prefer if it could go first and add new
user on top. But I realize that you are maintaining your series for a
_long_ time so I would completely understand if you wouldn't be
impressed by another rebase...

If you are OK with rebasing and I will help you with that as much as I
can I would be really grateful.

---
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 69188841717a..66e74928c2f0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2260,6 +2260,10 @@ config ARCH_ENABLE_MEMORY_HOTPLUG
 	def_bool y
 	depends on X86_64 || (X86_32 && HIGHMEM)
 
+config ARCH_HAS_ADD_PAGES
+	def_bool y
+	depends on X86_64 && ARCH_ENABLE_MEMORY_HOTPLUG
+
 config ARCH_ENABLE_MEMORY_HOTREMOVE
 	def_bool y
 	depends on MEMORY_HOTPLUG
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 754d47cb2847..ed1bb63d8f90 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -626,9 +626,9 @@ void __init paging_init(void)
  * After memory hotplug the variables max_pfn, max_low_pfn and high_memory need
  * updating.
  */
-static void  update_end_of_memory_vars(u64 start, u64 size)
+static void  update_end_of_memory_vars(u64 start_pfn, u64 nr_pages)
 {
-	unsigned long end_pfn = PFN_UP(start + size);
+	unsigned long end_pfn = start_pfn + nr_pages;
 
 	if (end_pfn > max_pfn) {
 		max_pfn = end_pfn;
@@ -637,22 +637,29 @@ static void  update_end_of_memory_vars(u64 start, u64 size)
 	}
 }
 
-int arch_add_memory(int nid, u64 start, u64 size, bool want_memblock)
+int add_pages(int nid, unsigned long start_pfn,
+	unsigned long nr_pages, bool want_memblock)
 {
-	unsigned long start_pfn = start >> PAGE_SHIFT;
-	unsigned long nr_pages = size >> PAGE_SHIFT;
 	int ret;
 
-	init_memory_mapping(start, start + size);
-
 	ret = __add_pages(nid, start_pfn, nr_pages, want_memblock);
 	WARN_ON_ONCE(ret);
 
 	/* update max_pfn, max_low_pfn and high_memory */
-	update_end_of_memory_vars(start, size);
+	update_end_of_memory_vars(start_pfn, nr_pages);
 
 	return ret;
 }
+
+int arch_add_memory(int nid, u64 start, u64 size, bool want_memblock)
+{
+	unsigned long start_pfn = start >> PAGE_SHIFT;
+	unsigned long nr_pages = size >> PAGE_SHIFT;
+
+	init_memory_mapping(start, start + size);
+
+	return add_pages(nid, start_pfn, nr_pages, want_memblock);
+}
 EXPORT_SYMBOL_GPL(arch_add_memory);
 
 #define PAGE_INUSE 0xFD
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index a9985f6c460a..a0973fc80e60 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -113,6 +113,14 @@ extern int __remove_pages(struct zone *zone, unsigned long start_pfn,
 extern int __add_pages(int nid, unsigned long start_pfn,
 	unsigned long nr_pages, bool want_memblock);
 
+#ifndef CONFIG_ARCH_HAS_ADD_PAGES
+static inline int add_pages(int nid, unsigned long start_pfn,
+	unsigned long nr_pages, bool want_memblock)
+{
+	return __add_pages(nid, start_pfn, nr_pages, want_memblock);
+}
+#endif
+
 #ifdef CONFIG_NUMA
 extern int memory_add_physaddr_to_nid(u64 start);
 #else
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1619021 — Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to arch_add/remove_memory

On Fri, Apr 07, 2017 at 07:59:12PM +0200, Michal Hocko wrote:
> On Fri 07-04-17 13:10:59, Jerome Glisse wrote:
> > On Fri, Apr 07, 2017 at 06:37:37PM +0200, Michal Hocko wrote:
> > > On Fri 07-04-17 12:10:00, Jerome Glisse wrote:
> [...]
> > > > No guaranteed so yes i somewhat care about max_pfn, i do not care about
> > > > any of its existing user last time i check but it might matter for some
> > > > new user.
> > > 
> > > OK, then we can add add_pages() which would do __add_pages by default
> > > (#ifndef ARCH_HAS_ADD_PAGES) and x86 would override it do also call
> > > update_end_of_memory_vars. This sounds easier to me than updating all
> > > the archs and add something that most of them do not really care about.
> > > 
> > > But I will not insist. If you think that your approach is better I will
> > > not object.
> > 
> > Something like attached patch ?
> 
> No I meant something like the diff below but maybe even that is too
> excessive.

No looks good to me at least. But i am no authority there.


> > > Btw. is your series reviewed and ready to be applied to the mm tree? I
> > > planed to post mine on Monday so I would like to know how do we
> > > coordinate. I rebase on topo of yours or vice versa.
> > 
> > Well v18 core patches were review by Mel, i did include all of his comment
> > in v19 (i don't think i did miss any). I think Dan still want to look at
> > patch 1 and 3 for ZONE_DEVICE.
> > 
> > But i always welcome more review. I know Anshuman replied to this patch
> > to improve a comments. Balbir had issue on powerpc because iomem_resource.end
> > isn't clamped to MAX_PHYSMEM_BITS But that is all review i got so far on v19.
> > 
> > I don't mind rebasing on top of your patchset. What ever is easier for
> > Andrew i guess.
> 
> Well, considering that my patchset is changing the behavior of the core
> of the memory hotplug I would prefer if it could go first and add new
> user on top. But I realize that you are maintaining your series for a
> _long_ time so I would completely understand if you wouldn't be
> impressed by another rebase...
> 
> If you are OK with rebasing and I will help you with that as much as I
> can I would be really grateful.


I don't mind rebasing on top of your patchset after you post. This is minor
change for me.

Cheers,
Jérôme

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web