Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree

[Andi Kleen <ak@muc.de>]

On Thu, Mar 23, 2006 at 09:36:09AM +0900, KAMEZAWA Hiroyuki wrote:
> On 23 Mar 2006 01:07:59 +0100
> Andi Kleen <ak@muc.de> wrote:
> 
> > On Thu, Mar 23, 2006 at 08:27:32AM +0900, KAMEZAWA Hiroyuki wrote:
> > > On 22 Mar 2006 20:21:34 +0100
> > > Andi Kleen <ak@muc.de> wrote:
> > > 
> > > > > It includes add-new-zone/rebuild-zonelist...etc patches, which will be necessary
> > > > > also for x86_64, even if it's not NUMA. 
> > > > 
> > > > Hmm? x86_64 supports NUMA systems.
> > > > 
> > > Ah, I know.
> > > I wrote "even if.." just because we cannot reserve mem_map for not exisiting node.
> > 
> > Hmm actually I haven't tested it but in theory the reserve hotplug
> > code should just work if you list the new nodes already in SRAT as empty
> > hotplug PXMs.
> > 
> SRAT is required by Microsoft, then most of servers will equip it, I think.
> And SRAT just tells each cpu's/memory range's  a pxm.
> 
> But allocating memmap for SRAT entry has some problem in big system.
> 
> For example, our server (ia64/Fujitsu PrimeQuest) can equip memory from
> 4G to 1T(maybe 2T in future), and SRAT will *always* say  we have possible 1T memory.
> (Microsoft requires "write all possible memory in SRAT") 
> When we reserve memmap for possible 1T memory, Linux will not work well in minimum 4G

Don't do that.
The x86-64 kernel will preallocate memmaps when everything is enabled soon.
Ok that won't concern your IA64 machine immediately.


> > Ok there is no code yet to add hotplug cpus to specific nodes later
> > but that would be easy to add.
> > 
> We found hot-add-memory-less-node problem now. So, "cpu hot add to a new node"  
> will be supported later.

Again should be pretty easy.

-Andi