Re: Non-contiguous physical memory on 8572

[Aaron Pace <kodiakuppercut@gmail.com>]

On Thu, Jul 2, 2009 at 3:14 PM, Scott Wood<scottwood@freescale.com> wrote:
> Aaron Pace wrote:
>>
>> 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. =A0This small change allows all
>> four gigabytes of memory to be accessed and used in my tests.
>>
>> Am I missing something obvious?
>
> The main downsides that I see are wasted memory for bookkeeping of the ho=
le
> (how acceptable this is depends on how large the hole is relative to the
> size of RAM -- it's a tradeoff against speed of looking up page structs),
> and that the reserved area may still be mapped in the TLB without the
> guarded bit set.
>
> -Scott
>
>

Ah, thanks for the response.
A couple of followup  clarifications/questions, if you don't mind.
As far as wasted memory for bookkeeping, aren't the reserved regions
excluded from any zonelist/pagetable allocation?  I'm looking through
to verify, but if you know off the top of your head where any extra
data would be required to keep track, I'd like to take a look to
further educate my memory manager understanding.

Secondly, can you elaborate on how/when the reserved area could be
mapped into the TLB?  I don't by any means lay claim to a complete
understanding of this area, but aside from a direct ioremap/mmap call,
how would this area get mapped at all?

Thanks again,
Aaron