Hello All,

 I would like to address the current state of hot-add memory and x86_64.
Broken is the word, neither add-path is functional at this time.   This
patch along with the rest of the series fixes up SPARSEMEM hot-add with
x86_64.  RESERVE_HOTADD is in a non-building state right now (since
2.6.18 or so) and I will have patches for this next.  

 My hardware is x86_64 ACPI hot-add enabled numa system (IBM x460
2node). 

There are 4 main issues that I have addressed:

1.  Merge MEMORY_HOTPLUG and RESERVE_HOT in srat.c.  Both add paths need
information from the SRAT as to node locality (RESERVE to reserve space
and MEMORY_HOTPLUG to figure out what node memory belongs to at add
time). I create a real config option for the RESERVE option in Kconfig
and share the code path.

2/3.  My hardware does not implement the optional passing along of the
pxm (node) information with the add memory event as the current acpi
driver expects.  I implement an arch_find_node call that will return the
node memory belongs to.  It uses the information saved from the SRAT. 

(Patches 1,2,3 allow intelligent numa additions of memory.  Presently
the acpi memory driver hands down -1 and things break)

4.  Kernel mapping fixup.  The kernel mapping (page table) code is
broken x86_64 for memory that is not aligned on a pud entry (pmd page).
I have fixed this limitation. 

5. ACPI fix needed for my hardware.  

There is another issue but I believe Kame already has a fix. It involves
sysfs on-lining large amounts of memory at one time instead of just a
section size. 

All comments welcome.  

keith mannthey <kmannth@us.ibm.com>
Linux Technology Center IBM