Re: [Lhms-devel] [RFC] patch [1/1] x86_64 numa aware sparsemem add_memory functinality

keith mannthey
2006-06-21T06:25:05Z

On Wed, 2006-06-21 at 15:06 +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 20 Jun 2006 22:43:01 -0700
> keith mannthey <kmannth@us.ibm.com> wrote:
>
> > Hello all,
> > This patch is an attempt to add a numa ware add_memory functionality
> > to x86_64 using CONFIG_SPARSEMEM. The add memory function today just
> > grabs the pgdat from node 0 and adds the memory there. On a numa system
> > this is functional but not optimal/correct.
> >
>
> At first, sorry for confusing.
> reserve_hotadd()/memory-hot-add with preallocated mem_map things are
> maintained by x86_64 and Andi Kleen (maybe).
> So we (lhms people) are not familiar with this.
Agreeded. I don't expect lhms to know much about reserve_hotadd().
Right now SPARSEMEM adds all it's memory to node 0 in x86_64. This is
the problem I am trying to fix. I doesn't make sense to me to rewrite
the SRAT code when RESERVE_HOTADD has done most of the work already.

> And yes, mem_map should be allocated from local node.
> I'm now preparing "dynamic local mem_map allocation" for lhms's memory hotplug,
> which doesn't depend on SRAT.

How do you know which node to add the memory too without something like
the SRAT that define memory locality of hot-add zones? SPARSEMEM doesn't
depend on SRAT (it just needs to use to to know what zone to add to.)

This patch isn't about mem_map allocation rather what zone to add the
memory to when doing SPASEMEM hot-add. A numa aware mem_map allocation
would belong in generic SPARSEMEM code.

>
> > The SRAT can expose future memory locality. This information is
> > already tracked by the nodes_add data structure (it keeps the
> > memory/node locality information) from the SRAT code. The code in
> > srat.c is built around RESERVE_HOTADD. This patch is a little subtle in
> > the way it uses the existing code for use with sparsemem. Perhaps
> > acpi_numa_memory_affinity_init needs a larger refactor to fit both
> > RESERVE_HOTADD and sparsemem.
> >
> > This patch still hotadd_percent as a flag to the whole srat parsing
> > code to disable and contain broken bios. It's functionality is retained
> > and an on off switch to sparsemem hot-add. Without changing the safety
> > mechanisms build into the current SRAT code I have provided a path for
> > the sparsemem hot-add path to get to the nodes_add data for use at
> > runtime.
> >
> > This is a 1st run at the patch, it works with 2.6.17
> >
> > Signed-off-by: Keith Mannthey <kmannth@us.ibm.com>
> >
>
>
>
> _______________________________________________
> Lhms-devel mailing list
> Lhms-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lhms-devel
--
keith mannthey <kmannth@us.ibm.com>
Linux Technology Center IBM