From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Shaohua Li <shaohua.li@intel.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: Mon, 6 Jul 2009 08:47:19 +0900 [thread overview]
Message-ID: <20090706084719.4f93179b.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <20090703091206.GA27930@sli10-desk.sh.intel.com>
On Fri, 3 Jul 2009 17:12:06 +0800
Shaohua Li <shaohua.li@intel.com> wrote:
> 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.
>
ZONE_MOVABLE is for that. I wonder current ZONE_MOVABLE interface is not enough.
If section should be removable later, the section should be onlined as ZONE_MOVABLE
as following.
example)
echo removable_online > /sys/devices/system/memory/memoryXXX/online
thx,
-Kame
> 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>
>
--
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>
prev parent reply other threads:[~2009-07-05 23:16 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
2009-07-05 23:47 ` KAMEZAWA Hiroyuki [this message]
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=20090706084719.4f93179b.kamezawa.hiroyu@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=shaohua.li@intel.com \
--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