Dave Hansen wrote:
> 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.
>
> i>>?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
>
>   
Ah, compromise :] that's why you get paid the big bux dave. thanks.