From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zhai, Edwin" Subject: Re: revisit the super page support in HVM restore Date: Wed, 19 Aug 2009 15:55:55 +0800 Message-ID: <4A8BB00B.6050000@intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; 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 19/08/2009 08:08, "Zhai, Edwin" wrote: > > >> So how about this new method: >> * Not tracking each of pfn inside 2M page, but trying best to allocate >> 2M pages if the 2M page covering this pfn is not allocated. >> * There may be holes inside new allocated 2M pages that are not synced in >> this batch, but we don't care and assume these missing pfns will >> come in future. >> >> This new method is simple as the super page support for PV guest is >> already there. >> > > You wil fail to restore a guest which has ballooned down its memory as there > will be 4k holes in its memory map. I see. But current PV guest has same issue also. If set superpages for the PV guest, allocate_mfn in xc_domain_restore.c would try to allocate 2M page for each of pfn regardless of the holes. Per my understanding, this is more serious issue for PV guest, as it uses balloon driver more frequently. If we have to use this algorithm, back to my complicated code -- do you have any suggestion to simplify the logic? Thanks, > You will allocate 2MB superpages despite > these holes, which do not get fixed up until end of restore process, and run > out of memory in the host, or against the guest's maxmem limit. > > -- Keir > > > -- best rgds, edwin