[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: super page with live migration
Keir Fraser wrote: On 26/9/08 08:45, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx> wrote:As you know, we try to allocate super pages in xc_hvm_build for better performance in EPT case. But the same logic is missing in xc_domain_restore. When try to add the logic, I found it is blocked by the lazy populatealgorithm in restore -- only populating the pages received from source side rather thandoing it at one time. So the result is the EPT guest has performance drop after live migration:( Do you have any plan to change the lazy populate algorithm? The purpose of it,I believe, is to make restore process work without guest memory layout knowledge.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. It's really tricky logic, and may make the migration process longer:( Maybe the flag the start-of-a-superpage as Tim said can make it easier. Thanks, -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |