Non-contiguous physical memory on 8572

[Kumar Gala]

On Jul 2, 2009, at 3:11 PM, Aaron Pace wrote:

> Hello,
>
> I wrote to this list quite some time ago concerning a board that has 2
> gigs of ram mapped in at 0x0.0000.0000 - 0x0.7fff.ffff, and a second 2
> gigs of ram at 0x1.0000.0000 - 0x1.7fff.ffff.  Kumar responded and
> mentioned that this wasn't currently supported in the powerpc
> architecture.  I've had this on my 'curiosity' back burner to take a
> look at for some time.
> I found a little time to look at this, and what I discovered is that
> this seems to actually have been a fairly trivial problem to solve.
> I'd like to get some feedback on the method I used, if possible, to
> see if I've overlooked something blatantly obvious.
>
> In MMU_init of arch/powerpc/mm/init_32.c, where the current code sets
> lmb.memory.cnt to zero, I instead walk through the memory regions and
> call lmb_reserve for each chunk of memory that lies in a 'hole'.
> There are then some minor fixups to make sure that total_memory and
> total_highmem get the right numbers.  This small change allows all
> four gigabytes of memory to be accessed and used in my tests.
>
> Am I missing something obvious?
> Would you like this in a patch for 32 or next, or is there a reason
> that this would not be desirable in the powerpc branch?

What you described is one possible solution.  However when I was  
thinking about support non-contiguous memory I was thinking about  
doing at based on CONFIG_DISCONTIGMEM (see include/asm-generic/ 
memory_model.h).  I think ppc64 supports SPARSEMEM which is a  
variation on the them.

- k