WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 1/2] PV hugepages - Xen patch

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 1/2] PV hugepages - Xen patch
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Thu, 9 Oct 2008 09:38:48 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Dave McCracken <dcm@xxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 09 Oct 2008 01:39:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48ED3950.1080605@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C512B667.1DFE2%keir.fraser@xxxxxxxxxxxxx> <48ED3950.1080605@xxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Wed, Oct 08, 2008 at 03:50:56PM -0700, Jeremy Fitzhardinge wrote:
> Keir Fraser wrote:
> >Actually this is an interesting one. For a PV guest it may be in general
> >unsolvable, since the target machine may not have allocatable 2MB extents.
> >It may also screw live migration since 2MB is a very coarse granularity to
> >do dirty-page tracking. One option: perhaps the PV kernel could shatter and
> >then reconstruct (as best it can) superpage mappings across save/restore?
> 
> That means you need to notify the guest when you're starting a live 
> migration, rather than just springing it on them at the last moment as 
> we do now.
> 
> But shattering large pages all over the place is going to be pretty 
> expensive, and possibly awkward if it suddenly needs to come up with a 
> pile of pages for the new L1 entries.

Or you could just take the view this is a pre-migration capability check,
and that admin (or mgmt app) must ensure sufficient free hugepages on the 
destination before attempting migration. If this isn't satisfied then
XenD can just fail / abort the migration op and leave it running on original
host.

Dainel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel