NUMA memory block size

[Benjamin Herrenschmidt]

On Sun, 2004-04-04 at 03:48, Olof Johansson wrote:
> On Sat, 3 Apr 2004, Dave Hansen wrote:
>
> > On Fri, 2004-04-02 at 22:50, Olof Johansson wrote:
> >
> > How about using the bootmem_alloc() functions instead of the LMB ones?
> > They're a bit more standard, and everyone else will realize what you're
> > doing.  That isn't too early, is it?
>
> I think it is. The array is built first thing in do_init_bootmem, so I
> wouldn't expect bootmem stuff to be available yet.

Still... That goes along with that work going on to clean up the
interface between prom_init and the rest of the kernel. I haven't looked
at the NUMA code proper in details yet, but at least one things that
stinks with the current LMBs is that the same data struture (fixed array
etc...) is used for the physical memory ranges detected _and_ reservation
of early boot memory.

>From experience, this is a huge waste of memory. A must small mecanism
could/should be used for reserving ranges of memory.

In fact, the whole thing could probably be killed in prom_init. By making
sure that copy_device_tree() is done _last_ in prom_init(), it's fairly
easy to _add_ OF nodes using OF "setprop" callback. The LMB for existing
physical memory can be completely removed, they aren't useful at this
point, a simple allocator can be built instead that parses the memory
nodes to "find" areas, and creates a "linux,reserved" property in thoses
with the reserved regions.

Then, from MMU init for example, (or whatever C code that is run late
enough to actually be out of the limited prom.c environment), the memory
nodes can be parsed to build the proper data structures, it's even possible
that we may have a working bootmem allocator at this point.

Ben.


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/