From: Geoff Levand <geoffrey.levand@am.sony.com>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
lkml <linux-kernel@vger.kernel.org>,
Yasunori Goto <y-goto@jp.fujitsu.com>
Subject: Re: [PATCH 5/5] [PPC] provide walk_memory_resource() for ppc
Date: Mon, 12 May 2008 17:17:02 -0700 [thread overview]
Message-ID: <4828DDFE.6050805@am.sony.com> (raw)
In-Reply-To: <1206664795.19368.13.camel@dyn9047017100.beaverton.ibm.com>
Hi,
I've had some trouble with this change.
Badari Pulavarty wrote:
> Provide walk_memory_resource() for ppc64. PPC maintains
> logic memory region mapping in lmb.memory structures. Walk
> through these structures and do the callbacks for the
> contiguous chunks.
...
> --- linux-2.6.25-rc3.orig/arch/powerpc/mm/mem.c 2008-03-05 10:14:28.000000000 -0800
> +++ linux-2.6.25-rc3/arch/powerpc/mm/mem.c 2008-03-05 10:32:16.000000000 -0800
> @@ -148,19 +148,35 @@ out:
>
> /*
> * walk_memory_resource() needs to make sure there is no holes in a given
> - * memory range. On PPC64, since this range comes from /sysfs, the range
> - * is guaranteed to be valid, non-overlapping and can not contain any
> - * holes. By the time we get here (memory add or remove), /proc/device-tree
> - * is updated and correct. Only reason we need to check against device-tree
> - * would be if we allow user-land to specify a memory range through a
> - * system call/ioctl etc. instead of doing offline/online through /sysfs.
> + * memory range. PPC64 does not maintain the memory layout in /proc/iomem.
> + * Instead it maintains it in lmb.memory structures. Walk through the
> + * memory regions, find holes and callback for contiguous regions.
> */
> 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);
> + struct lmb_property res;
> + unsigned long pfn, len;
> + u64 end;
> + int ret = -1;
> +
> + res.base = (u64) start_pfn << PAGE_SHIFT;
> + res.size = (u64) nr_pages << PAGE_SHIFT;
> +
> + end = res.base + res.size - 1;
> + while ((res.base < end) && (lmb_find(&res) >= 0)) {
^^^^^^^^^^^^^^
In the PS3 platform code (arch/pwerpc/platfroms/ps3/mm.c) the hotplug
memory is added like this:
...
result = add_memory(0, start_addr, map.r1.size);
...
result = online_pages(start_pfn, nr_pages);
...
In its work, online_pages() eventually calls walk_memory_resource(),
which has been changed as above to do a test on lmb_find(). I found
that this lmb_find() test always fails for PS3 since add_memory()
does not call lmb_add().
Is it the responsibility of the platform code to call lmb_add(), or
should that be done by add_memory()?
-Geoff
WARNING: multiple messages have this Message-ID (diff)
From: Geoff Levand <geoffrey.levand@am.sony.com>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
linuxppc-dev@ozlabs.org, paulus@samba.org,
Yasunori Goto <y-goto@jp.fujitsu.com>
Subject: Re: [PATCH 5/5] [PPC] provide walk_memory_resource() for ppc
Date: Mon, 12 May 2008 17:17:02 -0700 [thread overview]
Message-ID: <4828DDFE.6050805@am.sony.com> (raw)
In-Reply-To: <1206664795.19368.13.camel@dyn9047017100.beaverton.ibm.com>
Hi,
I've had some trouble with this change.
Badari Pulavarty wrote:
> Provide walk_memory_resource() for ppc64. PPC maintains
> logic memory region mapping in lmb.memory structures. Walk
> through these structures and do the callbacks for the
> contiguous chunks.
...
> --- linux-2.6.25-rc3.orig/arch/powerpc/mm/mem.c 2008-03-05 10:14:28.000000000 -0800
> +++ linux-2.6.25-rc3/arch/powerpc/mm/mem.c 2008-03-05 10:32:16.000000000 -0800
> @@ -148,19 +148,35 @@ out:
>
> /*
> * walk_memory_resource() needs to make sure there is no holes in a given
> - * memory range. On PPC64, since this range comes from /sysfs, the range
> - * is guaranteed to be valid, non-overlapping and can not contain any
> - * holes. By the time we get here (memory add or remove), /proc/device-tree
> - * is updated and correct. Only reason we need to check against device-tree
> - * would be if we allow user-land to specify a memory range through a
> - * system call/ioctl etc. instead of doing offline/online through /sysfs.
> + * memory range. PPC64 does not maintain the memory layout in /proc/iomem.
> + * Instead it maintains it in lmb.memory structures. Walk through the
> + * memory regions, find holes and callback for contiguous regions.
> */
> 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);
> + struct lmb_property res;
> + unsigned long pfn, len;
> + u64 end;
> + int ret = -1;
> +
> + res.base = (u64) start_pfn << PAGE_SHIFT;
> + res.size = (u64) nr_pages << PAGE_SHIFT;
> +
> + end = res.base + res.size - 1;
> + while ((res.base < end) && (lmb_find(&res) >= 0)) {
^^^^^^^^^^^^^^
In the PS3 platform code (arch/pwerpc/platfroms/ps3/mm.c) the hotplug
memory is added like this:
...
result = add_memory(0, start_addr, map.r1.size);
...
result = online_pages(start_pfn, nr_pages);
...
In its work, online_pages() eventually calls walk_memory_resource(),
which has been changed as above to do a test on lmb_find(). I found
that this lmb_find() test always fails for PS3 since add_memory()
does not call lmb_add().
Is it the responsibility of the platform code to call lmb_add(), or
should that be done by add_memory()?
-Geoff
next prev parent reply other threads:[~2008-05-13 0:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-28 0:33 [PATCH 0/5] 2.6.25-rc5-mm1 hotplug memory remove updates Badari Pulavarty
2008-03-28 0:33 ` Badari Pulavarty
2008-03-28 0:35 ` [PATCH 1/5] generic __remove_pages() support Badari Pulavarty
2008-03-28 0:35 ` Badari Pulavarty
2008-03-28 2:26 ` Yasunori Goto
2008-03-28 2:26 ` Yasunori Goto
2008-03-28 0:37 ` [PATCH 2/5] [PPC] htab_remove_mapping() error handling Badari Pulavarty
2008-03-28 0:37 ` Badari Pulavarty
2008-03-28 0:38 ` [PATCH 3/5] [PPC] hotplug memory notifications for ppc Badari Pulavarty
2008-03-28 0:38 ` Badari Pulavarty
2008-03-28 0:39 ` [PATCH 4/5] [PPC] update lmb for hotplug memory add/remove Badari Pulavarty
2008-03-28 0:39 ` Badari Pulavarty
2008-03-28 2:40 ` Kumar Gala
2008-03-28 2:40 ` Kumar Gala
2008-03-28 16:52 ` Badari Pulavarty
2008-03-28 16:52 ` Badari Pulavarty
2008-05-15 6:49 ` Benjamin Herrenschmidt
2008-05-15 6:49 ` Benjamin Herrenschmidt
2008-03-28 0:39 ` [PATCH 5/5] [PPC] provide walk_memory_resource() for ppc Badari Pulavarty
2008-03-28 0:39 ` Badari Pulavarty
2008-05-13 0:17 ` Geoff Levand [this message]
2008-05-13 0:17 ` Geoff Levand
2008-05-13 15:09 ` Badari Pulavarty
2008-05-13 15:09 ` Badari Pulavarty
-- strict thread matches above, loose matches on Subject: below --
2008-03-06 18:54 [PATCH 0/5] 2.6.25-rc3-mm1 hotplug memory remove updates Badari Pulavarty
2008-03-06 18:59 ` [PATCH 5/5] [PPC] provide walk_memory_resource() for ppc Badari Pulavarty
2008-03-06 18:59 ` Badari Pulavarty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4828DDFE.6050805@am.sony.com \
--to=geoffrey.levand@am.sony.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=pbadari@us.ibm.com \
--cc=y-goto@jp.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.