Re: [XenPPC] [RFC] 64mb Chunk Allocator

[Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>]

How is this expected to be integrated into existing memory allocators in
Xen?  Would the other allocators always allocate their own chunks to
work with and divide them up into smaller pieces or would other
allocators compete with the chunk allocator?

Whereas the allocation strategies chosen by Linux encourage
fragmentation and make memory hot-unplug difficult, this could be an
opportunity to introduce a generic large-granularity memory-management
layer that makes it easier to deal with hot-plug and large pages.

-- 
Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>

On Thu, 2006-06-22 at 16:39 -0400, Dan E Poff wrote:
> 
> For Xen on PPC, each domain needs a section of real memory, starting
> at 'real address' 0x0, allowing code to run with translate off. The
> PPC LPAR facility allows a unique chunk of memory to be 'mapped' at
> real address 0x0 for each partition (via RMOR). Minimum size of a
> chunk is 64mb, and requires alignment. Today's Xen code sets-up a
> single 64mb chunk for each domain. 
> 
> Proposal: (my interpretation of Jimi's ideas...) 
>         Simple 64mb chunk allocator, allowing multiple chunks per
> domain, and freeing chunks when a domain is destroyed 
> 
> Implementation: 
>         - Find installed memory using 'ofd' structure. Currently
> memory discovery stops at 1st hole (whether I/O or sparse). 
>         - Use bit-vector to indicate available chunks; atomic updating
> for SMP 
>         - Linux 'sparse memory support' will allow holes between 64mb
> chunks within domain 
> _______________________________________________
> Xen-ppc-devel mailing list
> Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ppc-devel

> 


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel