* Non-contiguous physical memory on 8572
@ 2009-07-02 20:11 Aaron Pace
2009-07-02 21:05 ` Kumar Gala
2009-07-02 21:14 ` Scott Wood
0 siblings, 2 replies; 5+ messages in thread
From: Aaron Pace @ 2009-07-02 20:11 UTC (permalink / raw)
To: linuxppc-dev
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?
Thanks,
Aaron
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Non-contiguous physical memory on 8572
2009-07-02 20:11 Non-contiguous physical memory on 8572 Aaron Pace
@ 2009-07-02 21:05 ` Kumar Gala
2009-07-02 21:14 ` Scott Wood
1 sibling, 0 replies; 5+ messages in thread
From: Kumar Gala @ 2009-07-02 21:05 UTC (permalink / raw)
To: Aaron Pace; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Non-contiguous physical memory on 8572
2009-07-02 20:11 Non-contiguous physical memory on 8572 Aaron Pace
2009-07-02 21:05 ` Kumar Gala
@ 2009-07-02 21:14 ` Scott Wood
2009-07-02 21:56 ` Aaron Pace
1 sibling, 1 reply; 5+ messages in thread
From: Scott Wood @ 2009-07-02 21:14 UTC (permalink / raw)
To: Aaron Pace; +Cc: linuxppc-dev
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. This 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
hole (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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Non-contiguous physical memory on 8572
2009-07-02 21:14 ` Scott Wood
@ 2009-07-02 21:56 ` Aaron Pace
2009-07-06 16:23 ` Scott Wood
0 siblings, 1 reply; 5+ messages in thread
From: Aaron Pace @ 2009-07-02 21:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Non-contiguous physical memory on 8572
2009-07-02 21:56 ` Aaron Pace
@ 2009-07-06 16:23 ` Scott Wood
0 siblings, 0 replies; 5+ messages in thread
From: Scott Wood @ 2009-07-06 16:23 UTC (permalink / raw)
To: Aaron Pace; +Cc: linuxppc-dev
On Thu, Jul 02, 2009 at 03:56:39PM -0600, Aaron Pace wrote:
> 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?
Linux maps low memory (up to 768MiB) regardless of reserved regions --
the assumption is that it can't be clobbered, not that it isn't RAM.
-Scott
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-07-06 16:23 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-02 20:11 Non-contiguous physical memory on 8572 Aaron Pace
2009-07-02 21:05 ` Kumar Gala
2009-07-02 21:14 ` Scott Wood
2009-07-02 21:56 ` Aaron Pace
2009-07-06 16:23 ` Scott Wood
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox