Re: Non-contiguous physical memory on 8572
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Non-contiguous physical memory on 8572
On Thu, Jul 2, 2009 at 3:14 PM, Scott Wood 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. 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 > > 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Non-contiguous physical memory on 8572
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Non-contiguous physical memory on 8572
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.. - 0x0.7fff., and a second 2 gigs of ram at 0x1.. - 0x1.7fff.. 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
