From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 0 of 8] NUMA Awareness for the Credit Scheduler Date: Tue, 9 Oct 2012 11:45:49 +0100 Message-ID: <1349779549.3610.79.camel@Abyss> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6474399870298097468==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dan Magenheimer Cc: Marcus Granado , Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , xen-devel@lists.xen.org, Jan Beulich , Daniel De Graaf , Matt Wilson List-Id: xen-devel@lists.xenproject.org --===============6474399870298097468== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-w+aA4+pB88wxPdPKsjx3" --=-w+aA4+pB88wxPdPKsjx3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2012-10-08 at 12:43 -0700, Dan Magenheimer wrote:=20 > Just wondering... is the NUMA information preserved on live migration? > I'm not saying that it necessarily should, but it may just work > due to the implementation (since migration is a form of domain creation). > What could I say... yes, but "preserved" is not the right word. :-) In fact, something happens when you migrate a VM. As you said, migration is a special case of domain creation, so the placement algorithm will trigger as a part of the process of creating the target VM (unless you override the relevant options in the config file during migration itself). That means the target VM will be placed on one (some) node(s) of the target host, and it's node-affinity will be set accordingly. _However_, there is right now no guarantee for the final decision from the placing algorithm on the target machine to be "compatible" with the one made on the source machine at initial VM creation time. For instance, if your VM fits in just one node and is placed there on machine A, it well could end up being split on two or more nodes when migrated on machine B (and, of course, the vice versa). Whether, that is acceptable or not, is of course debatable, and we had a bit of this discussion already (although no real conclusion has been reached yet). My take is that, right now, since we do not yet expose any virtual NUMA topology to the VM itself, the behaviour described above is fine. As soon as we'll have some guest NUMA awareness, than it might be worthwhile to try to preserve it, at least to some extent. Oh, and BTW, I'm of course talking about migration with xl and libxl. If you use other toolstacks, then the hypervisor will default to his current (_without_ this series) behaviour, and it all will depend on who and when calls xc_domain_node_setaffinity() or, perhaps, XEN_DOMCTL_setnodeaffinity directly. > In either case, it might be good to comment about live migration > on your wiki. >=20 That is definitely a good point, I will put something there about migration and the behaviour described above. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-w+aA4+pB88wxPdPKsjx3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlB0AF0ACgkQk4XaBE3IOsQccwCeNYFklEwDYJzDOLh+qPLqOMge f7MAoJSguSDFpKUDce3ddERuWPfkRqVX =pacC -----END PGP SIGNATURE----- --=-w+aA4+pB88wxPdPKsjx3-- --===============6474399870298097468== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6474399870298097468==--