[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |