From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zhai, Edwin" Subject: Re: super page with live migration Date: Sat, 27 Sep 2008 17:19:15 +0800 Message-ID: <48DDFA93.7070607@intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 26/9/08 08:45, "Zhai, Edwin" 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 populate >> algorithm >> in restore -- only populating the pages received from source side rather than >> doing 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 > > >