[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [XenPPC] domain physical to machine address translation
I was talking with Ryan yesterday, and we settled on a scheme to resolve some of our current memory management ugliness. If we have a notification hook in the XEN_DOMCTL_max_mem handler, we could size an array for each domain containing a pointer into the frame_table per page. There are already hooks in increase/decrease_reservation, except we aren't using them! In particular: * When a domain's max_page is set, we allocate an appropriately sized array of pointers, initialized to NULL. * increase_reservation() calls guest_physmap_add_page() with domain, pfn, and mfn. domain->p2m[pfn] = mfn_to_page(mfn) * decrease_reservation() calls guest_physmap_remove_page() with the same parameters. domain->p2m[pfn] = NULL Benefits: * slightly simplify pfn2mfn(); in particular we could remove the RMA check, the extent list walk, and the grant table check. I think the IO and foreign checks wouldn't be as trivial, but maybe we could figure that out later * drastically improves performance for accessing high addresses in large domains (avoids the extent list walk) * enables memory ballooning, although some Linux work needed to avoid the RMA. By my calculations (which always need to be double-checked ;) the memory consumption of a pointer per page would be 1/500th, e.g. a 1GB domain would require a 2MB array. This memory would probably need to be allocated from the domain heap to avoid exhausting the Xen heap. We don't need to use an array long-term, though I think it's the easiest initial implementation. The simplest version of this patch would just replace the RMA and extent list walking in pfn2mfn(), so it's nothing radical. -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-ppc-devel mailing list Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ppc-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |