Re: sparsemem support for mips with highmem

[Dave Hansen <dave@xxxxxxxxxxxxxxxxxx>]

On Fri, 2008-08-15 at 10:16 -0700, C Michael Sundius wrote:
> Ah, your right. thanks.  "but it's not necessar*il*y a good idea".
> That 
> is to say, we don't put
> memory above 2 GiB. No need to make the mem_section[] array bigger
> than 
> need be.
> 
> This gives further credence for it to be a configurable in Kconfig as
> well.

I definitely don't want it to be something that users see.  It is never
enough overhead to really care.  On a 16TB system with 16MB sections,
the mem_section[] array is still only 16MB!!

So, I'd say to just make it as big as the arch needs in the worst case
(smallest SECTION_SIZE_BITS and largest MAX_PHYSMEM_BITS) and leave it.
We might even want to merge the 32 and 64-bit versions.

For your 32-bit version, we now use:
8 bytes (2 32-bit words) for each mem_section[]
2GB/128MB sections = 16
So, that's only 512 bytes.

For the 64-bit version, we now use:
16 bytes (2 64-bit words) for each mem_section[]
32GB/256MB sections = 128
So, that's only 2048 bytes.

If we were to merge the 32 and 64-bit versions to:
#define SECTION_SIZE_BITS       27
#define MAX_PHYSMEM_BITS        35

Your 32-bit version would go to 2048 bytes, and the 64-bit version would
go to 4096 bytes.  The 32-bit version would we able to address more
memory, and the 64-bit version would be able to handle smaller memory
holes more efficiently. 

-- Dave