From: Shaohua Li <shaohua.li@intel.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Christoph Lameter <cl@linux-foundation.org>,
Yasunori Goto <y-goto@jp.fujitsu.com>,
"Zhao, Yakui" <yakui.zhao@intel.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mel@csn.ul.ie" <mel@csn.ul.ie>
Subject: Re: + memory-hotplug-alloc-page-from-other-node-in-memory-online.patch added to -mm tree
Date: Fri, 3 Jul 2009 17:12:06 +0800 [thread overview]
Message-ID: <20090703091206.GA27930@sli10-desk.sh.intel.com> (raw)
In-Reply-To: <20090703085556.fc711310.kamezawa.hiroyu@jp.fujitsu.com>
On Fri, Jul 03, 2009 at 07:55:56AM +0800, KAMEZAWA Hiroyuki wrote:
> On Thu, 2 Jul 2009 09:31:04 -0400 (EDT)
> Christoph Lameter <cl@linux-foundation.org> wrote:
>
> > On Thu, 2 Jul 2009, Yasunori Goto wrote:
> >
> > > However, I don't enough time for memory hotplug now,
> > > and they are just redundant functions now.
> > > If someone create new allocator (and unifying bootmem allocator),
> > > I'm very glad. :-)
> >
> > "Senior"ities all around.... A move like that would require serious
> > commitment of time. None of us older developers can take that on it
> > seems.
> >
> > Do we need to accept that the zone and page metadata are living on another
> > node?
> >
> I don't think so. Someone should do. I just think I can't do it _now_.
> (because I have more things to do for cgroup..)
>
> And, if not node-hotplug, memmap is allocated from local memory if possible.
> "We should _never_ allow fallback to other nodes or not" is problem ?
> I think we should allow fallback.
> About pgdat, zones, I hope they will be on-cache...
>
> Maybe followings are necessary for allocating pgdat/zones from local node
> at node-hotplug.
>
> a) Add new tiny functions to alloacate memory from not-initialized area.
> allocate pgdat/memmap from here if necessary.
> b) leave allocated memory from (a) as PG_reserved at onlining.
> c) There will be "not unpluggable" section after (b). We should show this to
> users.
> d) For removal, we have to keep precise trace of PG_reserved pages.
> e) vmemmap removal, which uses large page for vmemmap, is a problem.
> edges of section memmap is not aligned to large pages. Then we need
> some clever trick to handle this.
>
> Allocationg memmap from its own section was an idea (I love this) but
> IBM's 16MB memory section doesn't allow this.
Adding code for allocation should not be hard, but hard to make the memory
unpluggable. For example, the vmemmap page table pages can map several
sections and even several nodes (a pgd page). This will make some sections
completely not unpluggable if the sections have page table pages.
Is it possible we can merge the workaround temporarily? Without it, the hotplug
fails immediately in our side.
Thanks,
Shaohua
--
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:[~2009-07-03 9:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200906291949.n5TJnuov028806@imap1.linux-foundation.org>
[not found] ` <alpine.DEB.1.10.0906291804340.21956@gentwo.org>
2009-06-30 0:47 ` Shaohua Li
2009-07-01 2:55 ` Shaohua Li
2009-07-01 3:39 ` yakui
2009-07-01 17:22 ` Christoph Lameter
2009-07-02 1:11 ` yakui
2009-07-02 1:22 ` KAMEZAWA Hiroyuki
2009-07-02 5:59 ` Yasunori Goto
2009-07-02 13:31 ` Christoph Lameter
2009-07-02 23:55 ` KAMEZAWA Hiroyuki
2009-07-03 9:12 ` Shaohua Li [this message]
2009-07-05 23:47 ` KAMEZAWA Hiroyuki
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=20090703091206.GA27930@sli10-desk.sh.intel.com \
--to=shaohua.li@intel.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=y-goto@jp.fujitsu.com \
--cc=yakui.zhao@intel.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