All of lore.kernel.org
 help / color / mirror / Atom feed
From: keith mannthey <kmannth@us.ibm.com>
To: "Mika Penttilä" <mika.penttila@kolumbus.fi>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	lkml <linux-kernel@vger.kernel.org>,
	lhms-devel <lhms-devel@lists.sourceforge.net>,
	y-goto@jp.fujitsu.com, andrew <akpm@osdl.org>
Subject: Re: [PATCH] memory hotadd fixes [4/5] avoid check in acpi
Date: Fri, 04 Aug 2006 01:32:04 -0700	[thread overview]
Message-ID: <1154680324.5925.107.camel@keithlap> (raw)
In-Reply-To: <44D3041E.501@kolumbus.fi>

On Fri, 2006-08-04 at 11:23 +0300, Mika Penttilä wrote:
> keith mannthey wrote:
> > On Fri, 2006-08-04 at 12:48 +0900, KAMEZAWA Hiroyuki wrote:
> >   
> >> On Thu, 03 Aug 2006 20:23:46 -0700
> >> keith mannthey <kmannth@us.ibm.com> wrote:
> >>     
> >
> >   
> >>>>> What keeps 0xa0000000 to 0xa1000000 from being re-onlined by a bad call
> >>>>> to add_memory?
> >>>>>           
> >>>> Usual sparsemem's add_memory() checks whether there are sections in
> >>>> sparse_add_one_section(). then add_pages() returns -EEXIST (nothing to do).
> >>>> And ioresouce collision check will finally find collision because 0-0xbffffff
> >>>> resource will conflict with 0xa0000000 to 0xa10000000 area.
> >>>> But, x86_64 's (not sparsemem) add_pages() doen't do collision check, so it panics.
> >>>>         
> >>> I have paniced with your 5 patches while doing SPARSMEM....  I think
> >>> your 6th patch address the issues I was seeing.  
> >>>
> >>>       
> >
> >
> > with the 6 patches things work as expected.  It is nice to have the
> > sysfs devices online the correct amount of memory.  
> >
> > I was broken without this patch because invalid add_memory calls are
> > made on by box (yet another issue) during boot. 
> >
> > I will build my patch set on top of your 6 patches. 
> >
> > Thanks,
> >   Keith 
> >
> >   
> Keith, are you working on the reserve hotadd case? It looks really 
> broken, at the same time we both assume the hot add region contains RAM 
> per e820 (use of reserve_bootmem_node()) and at the same time in other 
> places (in reserve_hotadd()) that it may not contain RAM. And 
> nodes_cover_memory() is broken no matter what we assume.

I am working that right now... There is handful of things that need
cleaned up with RESERVE.  I am about 1 patch away for a patchset that
make both SPARSEMEM and RESERVE hot-add work on x86_64. It should be out
soon. 

Reserve is in a non-compile state as it stands with 2.6.18. 

Thanks,
 Keith 


  reply	other threads:[~2006-08-04  8:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-03  3:36 [PATCH] memory hotadd fixes [4/5] avoid check in acpi KAMEZAWA Hiroyuki
2006-08-03 18:28 ` keith mannthey
2006-08-03 23:09   ` [Lhms-devel] " keith mannthey
2006-08-04  0:22     ` KAMEZAWA Hiroyuki
2006-08-04  0:13 ` keith mannthey
2006-08-04  0:44   ` KAMEZAWA Hiroyuki
2006-08-04  1:54     ` keith mannthey
2006-08-04  2:15       ` KAMEZAWA Hiroyuki
2006-08-04  2:32         ` [PATCH] memory hotadd fixes [6/5] enhance collistion check KAMEZAWA Hiroyuki
2006-08-04  3:09           ` keith mannthey
2006-08-04  3:19             ` KAMEZAWA Hiroyuki
2006-08-04 21:01           ` keith mannthey
2006-08-04  3:00         ` [PATCH] memory hotadd fixes [4/5] avoid check in acpi keith mannthey
2006-08-04  3:13           ` KAMEZAWA Hiroyuki
2006-08-04  3:23             ` keith mannthey
2006-08-04  3:48               ` KAMEZAWA Hiroyuki
2006-08-04  4:25                 ` keith mannthey
2006-08-04  4:32                   ` KAMEZAWA Hiroyuki
2006-08-04  8:23                   ` Mika Penttilä
2006-08-04  8:32                     ` keith mannthey [this message]
2006-08-04  5:46                 ` Yasunori Goto
2006-08-04  5:59                   ` [Lhms-devel] " 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=1154680324.5925.107.camel@keithlap \
    --to=kmannth@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.penttila@kolumbus.fi \
    --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.