On Fri, 2006-09-01 at 14:07 -0500, Hollis Blanchard wrote:
> It sounds like Jimi wants to convince me that our domain memory
> allocation path (i.e. increase_reservation) should be different from
> everybody else's. Right now he's tracking non-RMA memory (for dom0 only)
> in large-page-sized "extents", which is the list_for_each_entry() loop
> you see in pfn2mfn(). If domU allocation populated domain.arch.pe_list,
> I think pfn2mfn() would work. However, the normal memory allocation path
> (that xend uses) doesn't populate this list, and instead populates
> domain.page_list. 

Update: I've just checked in code that adds to the PPC-specific extent
list. The net is that I've booted a domU with 224 MB of memory (64MB RMA
size). Just put "memory = whatever" into your xm config file.

Jimi claims that x86 superpage people (i.e. Steve Hand) are going to
come up with some superpage solution, and when they do, anything we have
done will just be discarded. Accordingly, we have a hack.

This particular hack has very poor implications for ballooning (i.e.
decrease_reservation()). If we need ballooning before superpages are
solved, we'll likely have to revisit this. Also, performance will

Finally, my Maple only has 512 MB of memory, and 256MB of that goes to
Xen and dom0. Anybody with a big JS2x want to test with very large
memory sizes?

Hollis Blanchard
IBM Linux Technology Center

Xen-ppc-devel mailing list

Reply via email to