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

Reply via email to