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

      * 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

Reply via email to