From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dario Faggioli <raistlin@linux.it>
Subject: Re: [PATCH 2 of 2 RFC] xl: allow for moving the
 domain's memory when changing vcpu affinity
Date: Fri, 06 Jul 2012 16:14:29 +0200
Message-ID: <1341584069.25268.33.camel@Solace>
References: <patchbomb.1341568443@Solace>
	<89aba27edf62271a4862.1341568445@Solace>
	<4FF6DFE5.7060403@eu.citrix.com>
	<1341583048.25268.28.camel@Solace> <4FF6F055.7040300@eu.citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8620529750222157689=="
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <4FF6F055.7040300@eu.citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Andre Przywara <andre.przywara@amd.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org


--===============8620529750222157689==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-GqXp6e7/mIU3m+a/jDEs"


--=-GqXp6e7/mIU3m+a/jDEs
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-07-06 at 15:04 +0100, George Dunlap wrote:
> > IOW, I think it would be worthwhile to have both the automatic memory
> > migration happening in background and something like this explicit,
> > do-it-all-now, as they serve different purposes.
> Well, I think you can have an explicit, do-it-now mechanism that doesn't=
=20
> require suspending the VM; and in fact, I think such a mechanism would=
=20
> be much preferable.
>=20
I fully agree on this.

> I'm not opposed to the -M option meaning, "...and please move the memory=
=20
> based on the new nodemask".  But I don't think implementing it as=20
> suspend/resume is really that useful, except as a stopgap measure until=
=20
> we can get "live" memory migration working. =20
>
I see, then we agree on everything, basically. :-P

> If we can get that before=20
> 4.3, there's no need for the stopgap measure.
>=20
Sure, that was the reason why it was an RFC after all... And it at least
triggered this discussion. :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-GqXp6e7/mIU3m+a/jDEs
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)

iEYEABECAAYFAk/28sUACgkQk4XaBE3IOsSeUwCeNi4QXWvdJiUA1uoC8YHup8WA
0XwAnRgpHvqQFDpIb6dTbWSC1qAXJWPR
=Tz6t
-----END PGP SIGNATURE-----

--=-GqXp6e7/mIU3m+a/jDEs--



--===============8620529750222157689==
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

--===============8620529750222157689==--