nice, some comments.
On Feb 14, 2007, at 11:54 AM, Hollis Blanchard wrote:

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.
Is domain->p2m that array?
Why pointers, you can decrease the array size if you keep it full of MFNs (which are u32s) which is good to 16TiB

      * increase_reservation() calls guest_physmap_add_page() with
        domain, pfn, and mfn. domain->p2m[pfn] = mfn_to_page(mfn)
domain->p2m[pfn] = mfn
      * decrease_reservation() calls guest_physmap_remove_page() with
        the same parameters. domain->p2m[pfn] = NULL
domain->p2m[pfn] = INVALID_MFN

What is the locking model?

IIRC it is possible to increase (but not decrease?) maxmem, so that would be an alloc, copy, free?

Will you allow increases that are not multiple of 16MiB of our current extents? Should we (trivially) teach linux not to use large pages to allow maximum freedom (after RMA)?
It would actually reduce our linux patch.


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

Thoughts,
on the 970 if you have more than 2GiB of memory then your frame_table will actually contain the IO area. In order to

* drastically improves performance for accessing high addresses in
        large domains (avoids the extent list walk)
Agreed!

      * 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,
1/512th.. please respect the powers of 2 :)
e.g. a 1GB domain
would require a 2MB array.

Moving to MFNs drops that down to 1MB

This memory would probably need to be
allocated from the domain heap to avoid exhausting the Xen heap.
I'd like to avoid messing up the domain heap, nothing is worse than having a lot of free memory no space that can be used for RMA. Since the needs of these arrays are quite predicable, 1 p2m[] entry for every mfn, we could accommodate for that in the Xen heap like we do for HTABs.


We don't need to use an array long-term, though I think it's the easiest
initial implementation.

agreed.


The simplest version of this patch would just replace the RMA and extent
list walking in pfn2mfn(), so it's nothing radical.

nice.

_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

Reply via email to