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