[RFC] PPC64 Exporting memory information through /proc/iomem

[RFC] PPC64 Exporting memory information through /proc/iomem

[Badari Pulavarty]

Hi Paul & Ben,

I am trying to get hotplug memory remove working on ppc64.
In order to verify a given memory region, if its valid or not -
current hotplug-memory patches used /proc/iomem. On IA64 and
x86-64 /proc/iomem shows all memory regions. 

I am wondering, if its acceptable to do the same on ppc64 also ?
Otherwise, we need to add arch-specific hooks in hotplug-remove
code to be able to do this.

Please comment. Here is the half-cooked patch I used to verify
the hotplug-memory-remove on ppc64.

Thanks,
Badari

---
 arch/powerpc/mm/numa.c |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

Index: linux-2.6.23-rc8/arch/powerpc/mm/numa.c
===================================================================
--- linux-2.6.23-rc8.orig/arch/powerpc/mm/numa.c	2007-10-02 10:16:42.000000000 -0700
+++ linux-2.6.23-rc8/arch/powerpc/mm/numa.c	2007-10-02 10:17:05.000000000 -0700
@@ -587,6 +587,22 @@ static void __init *careful_allocation(i
 	return (void *)ret;
 }
 
+static void add_regions_iomem()
+{
+	int i;
+	struct resource *res;
+
+	for (i = 0; i < lmb.memory.cnt; i++) {
+		res = alloc_bootmem_low(sizeof(struct resource));
+
+		res->name = "System RAM";
+		res->start = lmb.memory.region[i].base;
+		res->end = res->start + lmb.memory.region[i].size - 1;
+		res->flags = IORESOURCE_MEM;
+		request_resource(&iomem_resource, res);
+	}
+}
+
 static struct notifier_block __cpuinitdata ppc64_numa_nb = {
 	.notifier_call = cpu_numa_callback,
 	.priority = 1 /* Must run before sched domains notifier. */
@@ -650,6 +666,8 @@ void __init do_init_bootmem(void)
 
 		free_bootmem_with_active_regions(nid, end_pfn);
 
+		add_regions_iomem();
+
 		/* Mark reserved regions on this node */
 		for (i = 0; i < lmb.reserved.cnt; i++) {
 			unsigned long physbase = lmb.reserved.region[i].base;






--
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>

Re: [RFC] PPC64 Exporting memory information through /proc/iomem

[Geoff Levand]

Hi Badari,

Badari Pulavarty wrote:
> Hi Paul & Ben,
> 
> I am trying to get hotplug memory remove working on ppc64.
> In order to verify a given memory region, if its valid or not -
> current hotplug-memory patches used /proc/iomem. On IA64 and
> x86-64 /proc/iomem shows all memory regions. 
> 
> I am wondering, if its acceptable to do the same on ppc64 also ?
> Otherwise, we need to add arch-specific hooks in hotplug-remove
> code to be able to do this.


It seems the only reasonable place is in /proc/iomem, as the the 
generic memory hotplug routines put it in there, and if you have
a ppc64 system that uses add_memory() you will have mem info in
several places, none of which are complete.  


> Index: linux-2.6.23-rc8/arch/powerpc/mm/numa.c
> ===================================================================
> --- linux-2.6.23-rc8.orig/arch/powerpc/mm/numa.c	2007-10-02 10:16:42.000000000 -0700
> +++ linux-2.6.23-rc8/arch/powerpc/mm/numa.c	2007-10-02 10:17:05.000000000 -0700
> @@ -587,6 +587,22 @@ static void __init *careful_allocation(i
>  	return (void *)ret;
>  }
>  
> +static void add_regions_iomem()
> +{
> +	int i;
> +	struct resource *res;
> +
> +	for (i = 0; i < lmb.memory.cnt; i++) {
> +		res = alloc_bootmem_low(sizeof(struct resource));
> +
> +		res->name = "System RAM";
> +		res->start = lmb.memory.region[i].base;
> +		res->end = res->start + lmb.memory.region[i].size - 1;
> +		res->flags = IORESOURCE_MEM;
> +		request_resource(&iomem_resource, res);
> +	}
> +}
> +

I think this duplication of the code in register_memory_resource()
is a maintenance concern though.  I wonder if it would be better
to somehow hook your stuff into into the existing memory hotplug
routines.


-Geoff



--
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>

Re: [RFC] PPC64 Exporting memory information through /proc/iomem

[Badari Pulavarty]

On Tue, 2007-10-02 at 13:11 -0700, Geoff Levand wrote:
> Hi Badari,
> 
> Badari Pulavarty wrote:
> > Hi Paul & Ben,
> > 
> > I am trying to get hotplug memory remove working on ppc64.
> > In order to verify a given memory region, if its valid or not -
> > current hotplug-memory patches used /proc/iomem. On IA64 and
> > x86-64 /proc/iomem shows all memory regions. 
> > 
> > I am wondering, if its acceptable to do the same on ppc64 also ?
> > Otherwise, we need to add arch-specific hooks in hotplug-remove
> > code to be able to do this.
> 
> 
> It seems the only reasonable place is in /proc/iomem, as the the 
> generic memory hotplug routines put it in there, and if you have
> a ppc64 system that uses add_memory() you will have mem info in
> several places, none of which are complete.  

Well, this information exists in various places (lmb structures
in the kernel), /proc/device-tree for various users. I want to
find out what ppc experts think about making this available through
/proc/iomem also since generic memory hotplug routines expect 
it there.

Other option would be to provide arch-specific call out. Each
arch could decide to implement whatever way they want to verify 
the range.

Thanks,
Badari

--
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>

Re: [RFC] PPC64 Exporting memory information through /proc/iomem

[Geoff Levand]

Badari Pulavarty wrote:
> On Tue, 2007-10-02 at 13:11 -0700, Geoff Levand wrote:
>> Hi Badari,
>> 
>> Badari Pulavarty wrote:
>> > Hi Paul & Ben,
>> > 
>> > I am trying to get hotplug memory remove working on ppc64.
>> > In order to verify a given memory region, if its valid or not -
>> > current hotplug-memory patches used /proc/iomem. On IA64 and
>> > x86-64 /proc/iomem shows all memory regions. 
>> > 
>> > I am wondering, if its acceptable to do the same on ppc64 also ?
>> > Otherwise, we need to add arch-specific hooks in hotplug-remove
>> > code to be able to do this.
>> 
>> 
>> It seems the only reasonable place is in /proc/iomem, as the the 
>> generic memory hotplug routines put it in there, and if you have
>> a ppc64 system that uses add_memory() you will have mem info in
>> several places, none of which are complete.  
> 
> Well, this information exists in various places (lmb structures
> in the kernel), /proc/device-tree for various users. I want to
> find out what ppc experts think about making this available through
> /proc/iomem also since generic memory hotplug routines expect 
> it there.


Well, I can't say I am one of those experts you seek, but for PS3 we
already have the hotplug mem in /proc/iomem (I set it up to use
add_memory()), so it seems reasonable to have the bootmem there too.

-Geoff

--
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>

Re: [RFC] PPC64 Exporting memory information through /proc/iomem

[Paul Mackerras]

Badari Pulavarty writes:

> I am trying to get hotplug memory remove working on ppc64.
> In order to verify a given memory region, if its valid or not -
> current hotplug-memory patches used /proc/iomem. On IA64 and
> x86-64 /proc/iomem shows all memory regions. 
> 
> I am wondering, if its acceptable to do the same on ppc64 also ?

I am a bit hesitant to do that, since /proc/iomem is user visible and
is therefore part of the user/kernel ABI.  Also it feels a bit weird
to have system RAM in something whose name suggests it's about MMIO.

> Otherwise, we need to add arch-specific hooks in hotplug-remove
> code to be able to do this.

Isn't it just a matter of abstracting the test for a valid range of
memory?  If it's really hard to abstract that, then I guess we can put
RAM in iomem_resource, but I'd rather not.

Thanks,
Paul.

--
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>

Re: [RFC] PPC64 Exporting memory information through /proc/iomem

[Badari Pulavarty]

On Wed, 2007-10-03 at 08:56 +1000, Paul Mackerras wrote:
> Badari Pulavarty writes:
> 
> > I am trying to get hotplug memory remove working on ppc64.
> > In order to verify a given memory region, if its valid or not -
> > current hotplug-memory patches used /proc/iomem. On IA64 and
> > x86-64 /proc/iomem shows all memory regions. 
> > 
> > I am wondering, if its acceptable to do the same on ppc64 also ?
> 
> I am a bit hesitant to do that, since /proc/iomem is user visible and
> is therefore part of the user/kernel ABI.  Also it feels a bit weird
> to have system RAM in something whose name suggests it's about MMIO.

Yes. That was my first reaction. Until last week, I never realized
that /proc/iomem contains entire memory layout on i386/x86-64 :(

Since i386, x86-64 and ia64 are all doing same thing, I thought breakage
would be minimal (if any) if we do the same on ppc64.

> > Otherwise, we need to add arch-specific hooks in hotplug-remove
> > code to be able to do this.
> 
> Isn't it just a matter of abstracting the test for a valid range of
> memory?  If it's really hard to abstract that, then I guess we can put
> RAM in iomem_resource, but I'd rather not.
> 

Sure. I will work on it and see how ugly it looks.

KAME, are you okay with abstracting the find_next_system_ram() and
let arch provide whatever implementation they want ? (since current
code doesn't work for x86-64 also ?).

Thanks,
Badari

--
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>

Re: [RFC] PPC64 Exporting memory information through /proc/iomem

[KAMEZAWA Hiroyuki]

On Tue, 02 Oct 2007 16:10:53 -0700
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > > Otherwise, we need to add arch-specific hooks in hotplug-remove
> > > code to be able to do this.
> > 
> > Isn't it just a matter of abstracting the test for a valid range of
> > memory?  If it's really hard to abstract that, then I guess we can put
> > RAM in iomem_resource, but I'd rather not.
> > 
> 
> Sure. I will work on it and see how ugly it looks.
> 
> KAME, are you okay with abstracting the find_next_system_ram() and
> let arch provide whatever implementation they want ? (since current
> code doesn't work for x86-64 also ?).
> 
Hmm, registering /proc/iomem is complicated ? If too complicated, adding config
like
CONFIG_ARCH_SUPPORT_IORESOURCE_RAM or something can do good work.
you can define your own "check_pages_isolated" (you can rename this to
arch_check_apges_isolated().)


BTW, I shoudl ask people how to describe conventional memory

A. #define IORESOURCE_RAM		IORESOURCE_MEM	(ia64)
B. #define IORESOURCE_RAM		IORESOURCE_MEM | IORESOUCE_BUSY	(i386, x86_64)

Sad to say, memory hot-add registers new memory just as IORESOURCE_MEM.

Thanks,
-Kame

--
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>

Re: [RFC] PPC64 Exporting memory information through /proc/iomem

[Badari Pulavarty]

On Wed, 2007-10-03 at 10:19 +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 02 Oct 2007 16:10:53 -0700
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > > > Otherwise, we need to add arch-specific hooks in hotplug-remove
> > > > code to be able to do this.
> > > 
> > > Isn't it just a matter of abstracting the test for a valid range of
> > > memory?  If it's really hard to abstract that, then I guess we can put
> > > RAM in iomem_resource, but I'd rather not.
> > > 
> > 
> > Sure. I will work on it and see how ugly it looks.
> > 
> > KAME, are you okay with abstracting the find_next_system_ram() and
> > let arch provide whatever implementation they want ? (since current
> > code doesn't work for x86-64 also ?).
> > 
> Hmm, registering /proc/iomem is complicated ?

Its not complicated. Like Paul mentioned, its part of user/kernel API
which he is not prefering to break (if possible) + /proc/iomem seems
like a weird place to export conventional memory.

>  If too complicated, adding config
> like
> CONFIG_ARCH_SUPPORT_IORESOURCE_RAM or something can do good work.
> you can define your own "check_pages_isolated" (you can rename this to
> arch_check_apges_isolated().)

I was thinking more in the lines of 

CONFIG_ARCH_HAS_VALID_MEMORY_RANGE. Then define own
find_next_system_ram() (rename to is_valid_memory_range()) - which
checks the given range is a valid memory range for memory-remove
or not. What do you think ?

Thanks,
Badari

--
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>

Re: [RFC] PPC64 Exporting memory information through /proc/iomem

[KAMEZAWA Hiroyuki]

On Wed, 03 Oct 2007 08:35:35 -0700
Badari Pulavarty <pbadari@us.ibm.com> wrote:

> On Wed, 2007-10-03 at 10:19 +0900, KAMEZAWA Hiroyuki wrote:
> CONFIG_ARCH_HAS_VALID_MEMORY_RANGE. Then define own
> find_next_system_ram() (rename to is_valid_memory_range()) - which
> checks the given range is a valid memory range for memory-remove
> or not. What do you think ?
> 
My concern is...
Now, memory hot *add* makes use of resource(/proc/iomem) information for onlining
memory.(See add_memory()->register_memory_resource() in mm/memoryhotplug.c)
So, we'll have to consider changing it if we need.

Does PPC64 memory hot add registers new memory information to arch dependent
information list ? It seems ppc64 registers hot-added memory information from
*probe* file and registers it by add_memory()->register_memory_resource().

If you add all add/remove/walk system ram information in sane way, I have no
objection.

I like find_next_system_ram() because I used some amount of time to debug it ;)

Thanks,
-Kame

--
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>

Re: [RFC] PPC64 Exporting memory information through /proc/iomem

[Badari Pulavarty]

On Thu, 2007-10-04 at 01:25 +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 03 Oct 2007 08:35:35 -0700
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
> 
> > On Wed, 2007-10-03 at 10:19 +0900, KAMEZAWA Hiroyuki wrote:
> > CONFIG_ARCH_HAS_VALID_MEMORY_RANGE. Then define own
> > find_next_system_ram() (rename to is_valid_memory_range()) - which
> > checks the given range is a valid memory range for memory-remove
> > or not. What do you think ?
> > 
> My concern is...
> Now, memory hot *add* makes use of resource(/proc/iomem) information for onlining
> memory.(See add_memory()->register_memory_resource() in mm/memoryhotplug.c)
> So, we'll have to consider changing it if we need.
> 
> Does PPC64 memory hot add registers new memory information to arch dependent
> information list ? It seems ppc64 registers hot-added memory information from
> *probe* file and registers it by add_memory()->register_memory_resource().

Yes. Thats what I realized after looking at the code. 
I have been concentrating on memory remove, never care about "add" :(
Let me take a closer look at "add" support for ppc.

Thanks,
Badari

--
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>

[RFC] hotplug memory remove - walk_memory_resource for ppc64

[Badari Pulavarty]

Hi KAME,

As I mentioned while ago, ppc64 does not export information about
"system RAM" in /proc/iomem. Looking at the code and usage
scenerios I am not sure what its really serving. Could you 
explain what its purpose & how the range can be invalid ?

At least on ppc64, all the memory ranges we get passed comes from
/sysfs memblock information and they are guaranteed to match 
device-tree entries. On ppc64, each 16MB chunk has a /sysfs entry
and it will be part of the /proc/device-tree entry. Since we do
"online" or "offline" to /sysfs entries to add/remove pages - 
these ranges are guaranteed to be valid.

Since this check is redundant for ppc64, I propose following patch.
Is this acceptable ? If some one really really wants, I can code
up this to walk lmb or /proc/device-tree and verify the range &
adjust the entries for overlap (I don't see how that can happen).

Paul & Kame, please comment.

Thanks,
Badari

---
 arch/powerpc/Kconfig  |    3 +++
 arch/powerpc/mm/mem.c |   13 +++++++++++++
 kernel/resource.c     |    2 +-
 3 files changed, 17 insertions(+), 1 deletion(-)

Index: linux-2.6.24-rc1/arch/powerpc/mm/mem.c
===================================================================
--- linux-2.6.24-rc1.orig/arch/powerpc/mm/mem.c	2007-10-30 07:39:16.000000000 -0800
+++ linux-2.6.24-rc1/arch/powerpc/mm/mem.c	2007-10-30 10:05:09.000000000 -0800
@@ -129,6 +129,19 @@ int __devinit arch_add_memory(int nid, u
 	return __add_pages(zone, start_pfn, nr_pages);
 }
 
+/*
+ * I don't think we really need to do anything here to validate the memory
+ * range or walk the memory resource in lmb or device-tree. Only way we get
+ * the memory range here is through /sysfs in 16MB chunks and we are guaranteed
+ * to have a corresponding device-tree entry.
+ */
+int
+walk_memory_resource(unsigned long start_pfn, unsigned long nr_pages, void *arg,
+			int (*func)(unsigned long, unsigned long, void *))
+{
+	return  (*func)(start_pfn, nr_pages, arg);
+}
+
 #endif /* CONFIG_MEMORY_HOTPLUG */
 
 #ifdef CONFIG_MEMORY_HOTREMOVE
Index: linux-2.6.24-rc1/kernel/resource.c
===================================================================
--- linux-2.6.24-rc1.orig/kernel/resource.c	2007-10-23 20:50:57.000000000 -0700
+++ linux-2.6.24-rc1/kernel/resource.c	2007-10-30 08:58:41.000000000 -0800
@@ -228,7 +228,7 @@ int release_resource(struct resource *ol
 
 EXPORT_SYMBOL(release_resource);
 
-#ifdef CONFIG_MEMORY_HOTPLUG
+#if defined(CONFIG_MEMORY_HOTPLUG) && !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
 /*
  * Finds the lowest memory reosurce exists within [res->start.res->end)
  * the caller must specify res->start, res->end, res->flags.
Index: linux-2.6.24-rc1/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.24-rc1.orig/arch/powerpc/Kconfig	2007-10-30 07:39:17.000000000 -0800
+++ linux-2.6.24-rc1/arch/powerpc/Kconfig	2007-10-30 08:54:57.000000000 -0800
@@ -234,6 +234,9 @@ config HOTPLUG_CPU
 config ARCH_ENABLE_MEMORY_HOTPLUG
 	def_bool y
 
+config ARCH_HAS_WALK_MEMORY
+	def_bool y
+
 config ARCH_ENABLE_MEMORY_HOTREMOVE
 	def_bool y
 



--
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>

Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64

[KAMEZAWA Hiroyuki]

On Tue, 30 Oct 2007 11:19:11 -0800
Badari Pulavarty <pbadari@us.ibm.com> wrote:

> Hi KAME,
> 
> As I mentioned while ago, ppc64 does not export information about
> "system RAM" in /proc/iomem. Looking at the code and usage
> scenerios I am not sure what its really serving. Could you 
> explain what its purpose & how the range can be invalid ?
> 
Hm, I added walk_memory_resource() for hot-add, at first.

Size of memory section is fixed and just depend on architecture, but
any machine can have any memory-hole within continuous memory-section-size
range of physical memory. Then we have to detect which page can be
target of online_page() and which are leaved as Reserved.

ioresource was good structure for remembering "which memory is conventional
memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
when I posted patch. (just say "System Ram" is not for memory hotplug.)

I used walk_memory_resource() again in memory hotremove.

(If I rememember correctly, walk_memory_resouce() helps x86_64 memory hot-add.
 than our ia64 box.
 In our ia64 box, we do node-hotadd. Section size is 1GiB and it has some
 "for firmware" area in newly-added node.)

> At least on ppc64, all the memory ranges we get passed comes from
> /sysfs memblock information and they are guaranteed to match 
> device-tree entries. On ppc64, each 16MB chunk has a /sysfs entry
> and it will be part of the /proc/device-tree entry. Since we do
> "online" or "offline" to /sysfs entries to add/remove pages - 
> these ranges are guaranteed to be valid.
> 
ok.

> Since this check is redundant for ppc64, I propose following patch.
> Is this acceptable ? If some one really really wants, I can code
> up this to walk lmb or /proc/device-tree and verify the range &
> adjust the entries for overlap (I don't see how that can happen).
> 
ok. If ppc64 guarantees "there is no memory hole in section", please try.
I have no objection.
I just would like to ask to add some text to explain
"ppc64 doesn't need to care memory hole in a section."


Thanks,
-Kame

--
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>

Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64

[KAMEZAWA Hiroyuki]

On Wed, 31 Oct 2007 14:28:46 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:

> ioresource was good structure for remembering "which memory is conventional
> memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
> when I posted patch. (just say "System Ram" is not for memory hotplug.)
> 
If I remember correctly, System RAM is for kdump (to know which memory should
be dumped.) Then, memory-hotadd/remove has to modify it anyway.

Thanks,
-Kame

--
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>

Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64

[Badari Pulavarty]

On Wed, 2007-10-31 at 14:34 +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 31 Oct 2007 14:28:46 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> 
> > ioresource was good structure for remembering "which memory is conventional
> > memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
> > when I posted patch. (just say "System Ram" is not for memory hotplug.)
> > 
> If I remember correctly, System RAM is for kdump (to know which memory should
> be dumped.) Then, memory-hotadd/remove has to modify it anyway.

Yes. kdump uses it for finding memory holes on x86/x86-64 (not sure
about ia64). On PPC64, since its not represented in /proc/iomem, we
end up reading /proc/device-tree/memory* nodes to construct the 
memory map.

Paul's concern is, since we didn't need it so far - why we need this
for hotplug memory remove to work ? It might break API for *unknown*
applications. Its unfortunate that, hotplug memory add updates 
/proc/iomem. We can deal with it later, as a separate patch.

Thanks,
Badari

--
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>

Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64

[KAMEZAWA Hiroyuki]

On Wed, 31 Oct 2007 08:02:40 -0800
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> Paul's concern is, since we didn't need it so far - why we need this
> for hotplug memory remove to work ? It might break API for *unknown*
> applications. Its unfortunate that, hotplug memory add updates 
> /proc/iomem. We can deal with it later, as a separate patch.
> 
I have no objection to skip /proc/iomem related routine when arch
doesn't need it. 

My advice is just "please take care both of hot-add and hot-remove".

If ppc64 people agreed to use arch-specific routine for detect
conventional memory, there is no problem, I think.

Thanks,
-Kame

--
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>

[PATCH 0/3] hotplug memory remove support for PPC64

[Badari Pulavarty]

Hi Paul/Andrew,

Here are few minor fixes needed to get hotplug memory remove working
on ppc64. Could you please consider them for -mm ?

	[PATCH 1/3] Add remove_memory() for ppc64
	[PATCH 2/3] Enable hotplug memory remove for ppc64
	[PATCH 3/3] Add arch-specific walk_memory_remove() for ppc64

I am able to successfully add/remove memory on ppc64 with these patches.
ZONE_MOVABLE guarantees the success, if we really really want to be able
to remove memory.

Thanks to Mel and KAME for doing all the real work :) 

TODO:
	- I am running into migrate_pages() issues on reiserfs backed
files. Nothing to do with ppc64.

Thanks,
Badari




--
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>

Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64

[Badari Pulavarty]

On Wed, 2007-10-31 at 14:28 +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 30 Oct 2007 11:19:11 -0800
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
> 
> > Hi KAME,
> > 
> > As I mentioned while ago, ppc64 does not export information about
> > "system RAM" in /proc/iomem. Looking at the code and usage
> > scenerios I am not sure what its really serving. Could you 
> > explain what its purpose & how the range can be invalid ?
> > 
> Hm, I added walk_memory_resource() for hot-add, at first.
> 
> Size of memory section is fixed and just depend on architecture, but
> any machine can have any memory-hole within continuous memory-section-size
> range of physical memory. Then we have to detect which page can be
> target of online_page() and which are leaved as Reserved.
> 
> ioresource was good structure for remembering "which memory is conventional
> memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
> when I posted patch. (just say "System Ram" is not for memory hotplug.)
> 
> I used walk_memory_resource() again in memory hotremove.

Agreed. On PPC64, within a memblock represented in /sysfs are pretty
small (16MB) and there can not be any holes. And you can add/remove
memory only on 16MB multiple chunks. 

> 
> (If I rememember correctly, walk_memory_resouce() helps x86_64 memory hot-add.
>  than our ia64 box.
>  In our ia64 box, we do node-hotadd. Section size is 1GiB and it has some
>  "for firmware" area in newly-added node.)

> 
> > At least on ppc64, all the memory ranges we get passed comes from
> > /sysfs memblock information and they are guaranteed to match 
> > device-tree entries. On ppc64, each 16MB chunk has a /sysfs entry
> > and it will be part of the /proc/device-tree entry. Since we do
> > "online" or "offline" to /sysfs entries to add/remove pages - 
> > these ranges are guaranteed to be valid.
> > 
> ok.
> 
> > Since this check is redundant for ppc64, I propose following patch.
> > Is this acceptable ? If some one really really wants, I can code
> > up this to walk lmb or /proc/device-tree and verify the range &
> > adjust the entries for overlap (I don't see how that can happen).
> > 
> ok. If ppc64 guarantees "there is no memory hole in section", please try.
> I have no objection.
> I just would like to ask to add some text to explain
> "ppc64 doesn't need to care memory hole in a section."

Yes. I would like to go with this approach, rather than adding the
information to /proc/iomem (as per Paul's suggestion). If I find
cases where sections (16MB) *could* contain holes -OR- overlaps -
I can easily add code to verify against lmb/proc-device-tree information
easily without affecting arch-neutral code.

Thanks,
Badari

--
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>