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@xxxxxxxxxx
> > > > > > > [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
>From 7f414aef1e84c8ff65102e571f808f6362212350 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= <jglisse@xxxxxxxxxx>
Date: Fri, 7 Apr 2017 12:51:20 -0400
Subject: [PATCH] mm/memory_hotplug: add add_pages() hotplug without linear
mapping
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
For some memory hotplug we do not want the linear mapping to the
hotpluged physical range. Add a new helper that just do __add_pages()
and other arch specific bits if necessary.
Signed-off-by: Jérôme Glisse <jglisse@xxxxxxxxxx>
---
arch/x86/Kconfig | 1 +
arch/x86/mm/init_64.c | 17 ++++++++++++++++-
mm/Kconfig | 2 ++
mm/memory_hotplug.c | 18 ++++++++++++++++++
4 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cc98d5a..4024fee 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -25,6 +25,7 @@ config X86_64
select ARCH_HAS_GIGANTIC_PAGE
select ARCH_SUPPORTS_INT128
select ARCH_USE_CMPXCHG_LOCKREF
+ select ARCH_HAS_ADD_PAGES
select HAVE_ARCH_SOFT_DIRTY
select MODULES_USE_ELF_RELA
select X86_DEV_DMA_OPS
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 15173d3..933032c 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -626,7 +626,7 @@ 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, u64 size)
{
unsigned long end_pfn = PFN_UP(start + size);
@@ -662,6 +662,21 @@ int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
}
EXPORT_SYMBOL_GPL(arch_add_memory);
+int add_pages(int nid, struct zone *zone, unsigned long phys_start_pfn,
+ unsigned long nr_pages)
+{
+ int ret;
+
+ ret = __add_pages(nid, zone, phys_start_pfn, nr_pages);
+
+ if (!ret)
+ update_end_of_memory_vars(phys_start_pfn << PAGE_SHIFT,
+ nr_pages << PAGE_SHIFT);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(add_pages);
+
#define PAGE_INUSE 0xFD
static void __meminit free_pagetable(struct page *page, int order)
diff --git a/mm/Kconfig b/mm/Kconfig
index 9b8fccb..d052ec1 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -707,3 +707,5 @@ config ARCH_USES_HIGH_VMA_FLAGS
bool
config ARCH_HAS_PKEYS
bool
+config ARCH_HAS_ADD_PAGES
+ bool
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 295479b..bef772c 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -576,6 +576,24 @@ int __ref __add_pages(int nid, struct zone *zone, unsigned long phys_start_pfn,
}
EXPORT_SYMBOL_GPL(__add_pages);
+#ifndef ARCH_HAS_ADD_PAGES
+int add_pages(int nid, struct zone *zone, unsigned long phys_start_pfn,
+ unsigned long nr_pages)
+{
+ int ret;
+
+ ret = __add_pages(nid, zone, phys_start_pfn, nr_pages);
+
+#ifdef CONFIG_X86_64
+ if (!ret)
+ update_end_of_memory_vars(phys_start_pfn << PAGE_SHIFT,
+ nr_pages << PAGE_SHIFT);
+#endif
+ return ret;
+}
+EXPORT_SYMBOL_GPL(add_pages);
+#endif /* ARCH_HAS_ADD_PAGES */
+
#ifdef CONFIG_MEMORY_HOTREMOVE
/* find the smallest valid pfn in the range [start_pfn, end_pfn) */
static int find_smallest_section_pfn(int nid, struct zone *zone,
--
2.7.4
