| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Re: super page with live migration
> > Or flag the start-of-a-superpage frames when saving them?
>
> It's not clear to me this is significantly easier to hack in on the
save
> side, and restore side would still need modifying, and it would change
> the save format (albeit probably not hard to do it in a
backward-compatible
> way). I'm not absolutely dead set on my stated approach though.
Also, since you typically migrate VMs to less busy machines it would be
good to take the opportunity to use more 2MB frames.
>> Yes: If pseudo-phys page is not yet populated in target domain, AND
>> it is first page of a 2MB extent, AND no other pages in that extent
>> are yet populated, AND the next pages in the save-image stream
>> populate that extent in order, THEN allocate a superpage. This is
>> made trickier by the fact that the next 511 pages (to make the 2MB
>> extent) might be split across a batch boundary. So we'll have to
>> optimistically allocate a superpage in that case, and then shatter it
>> if it turns out that the contiguous stream of pseudo-phys addresses
is broken in the next batch.
Rather than shattering the 2MB frame, it would be better to copy the
pages out into a heap-allocated buffer, free the 2MB frame, and then
allocate order-0 pages and copy the data in.
This avoids needlessly fragmenting xen's memory.
Thanks,
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home