WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

Re: [XenPPC] 128 meg domU???

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
*suck*.

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
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel

<Prev in Thread] Current Thread [Next in Thread>