linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

      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