From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] libxc: try to find last used pfn when migrating Date: Fri, 27 Nov 2015 15:18:34 +0000 Message-ID: <1448637514.13576.110.camel@citrix.com> References: <1448635853-24865-1-git-send-email-jgross@suse.com> <5658705E.2090302@citrix.com> <565872AB.2050809@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <565872AB.2050809@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Juergen Gross , David Vrabel , xen-devel@lists.xen.org, ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com, andrew.cooper3@citrix.com List-Id: xen-devel@lists.xenproject.org On Fri, 2015-11-27 at 16:11 +0100, Juergen Gross wrote: > On 27/11/15 16:01, David Vrabel wrote: > > On 27/11/15 14:50, Juergen Gross wrote: > > > For migration the last used pfn of a guest is needed to size the > > > logdirty bitmap and as an upper bound of the page loop. Unfortunately > > > there are pv-kernels advertising a much higher maximum pfn as they > > > are really using in order to support memory hotplug. This will lead > > > to allocation of much more memory in Xen tools during migration as > > > really needed. > > > > > > Try to find the last used guest pfn of a pv-domu by scanning the p2m > > > tree from the last entry towards it's start and search for an entry > > > not being invalid. > > > > > > Normally the mid pages of the p2m tree containing all invalid entries > > > are being reused, so we can just scan the top page for identical > > > entries and skip them but the first one. > > > > This has been fixed in Linux by "x86/xen/p2m: hint at the last > > populated > > P2M entry" 98dd166ea3a3c3b57919e20d9b0d1237fcd0349d which is tagged for > > stable. > > > > Do we really need a toolstack fix as well? > > xl migrate will use much less resources for a domain with a 3.x kernel > started with max_mem being much larger than mem. E.g. in case you start > a domain on a small stand-by system and migrate it later to the large > production system and want to balloon it up there. > > Additionally there was a discussion this week on irc regarding this > topic and concern was raised this could block dom0 responsiveness. We certainly want the toolstack domain to be more resilient in the face of ludicrous guest-supplied numbers than it is today. Ian.