From: Dave Hansen <haveblue@us.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: y-goto@jp.fujitsu.com, akpm@osdl.org, tony.luck@intel.com,
ak@suse.de, linux-kernel@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())
Date: Tue, 21 Mar 2006 17:08:18 -0800 [thread overview]
Message-ID: <1142989698.10906.224.camel@localhost.localdomain> (raw)
In-Reply-To: <20060322090514.6d6826fc.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 2006-03-22 at 09:05 +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 21 Mar 2006 10:00:12 -0800
> Dave Hansen <haveblue@us.ibm.com> wrote:
> > At some point in the process, you need to export the NUMA node layout to
> > the rest of the system, to say which pages go in which node. I'm just
> > saying that you should do that _before_ add_memory().
> >
> To do so, we have to maintain new pfn_to_nid() function.
> We have to maintain a new table/list and have to consider name of it :).
I completely spaced out, and forgot that we use sparsemem and 'struct
pages' for pfn_to_nid() now. I've been buried too deep in the i386
discontigmem physnode_map[]. Sorry.
If I missed it before, please refresh my memory. But, if we're
providing arch_nid_probe(addr), then why don't we just call it inside of
add_memory() on the start address, instead of in the generic code?
I'm also getting a bit confused in your patches whether add_memory() is
the _original_ add_memory(), or the new one. It tends to get lost in 17
patches. :(
I don't really like the arch_nid_probe() name. We need to make it very
apparent that it is to be used _only_ for memory hotplug operations. It
has no meaning for anything else.
hotplug_physaddr_to_nid()?
Maybe with a "memory_" in front. Maybe even
memory_add_physaddr_to_nid()?
It was probably to keep from changing as little code as possible, but
please convert the u64 values to pfns as soon as possible. I noticed
that hotadd_new_pgdat() still deals with them, and does the shift as
well. Is that really necessary.
The u64s should not be kept for more than one level of calls. That
level of calls should be the firmware. So, let the firmware call into
the VM code with u64s, then have all of the plain VM code deal in pfns.
-- Dave
--
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>
next prev parent reply other threads:[~2006-03-22 1:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-17 8:20 Yasunori Goto
2006-03-17 17:12 ` Dave Hansen
2006-03-18 1:26 ` KAMEZAWA Hiroyuki
2006-03-21 18:00 ` Dave Hansen
2006-03-22 0:05 ` KAMEZAWA Hiroyuki
2006-03-22 1:08 ` Dave Hansen [this message]
2006-03-22 1:38 ` KAMEZAWA Hiroyuki
2006-03-22 6:06 ` Yasunori Goto
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=1142989698.10906.224.camel@localhost.localdomain \
--to=haveblue@us.ibm.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tony.luck@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox