From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 6 of 8 [RFC]] libxc: introduce xc_domain_move_memory Date: Tue, 9 Apr 2013 08:56:31 +0200 Message-ID: <1365490591.17022.14.camel@Abyss> References: <5163A5E4.6030608@ts.fujitsu.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7847547628211724519==" Return-path: In-Reply-To: <5163A5E4.6030608@ts.fujitsu.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 Cc: Dan Magenheimer , Ian Campbell , George Dunlap , Andrew Cooper , "Tim (Xen.org)" , Olaf Hering , xen-devel , David Vrabel , Keir Fraser , Andres Lagar-Cavilla , Jan Beulich , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org --===============7847547628211724519== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5itek+ExBseMQeyn0vy5" --=-5itek+ExBseMQeyn0vy5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mar, 2013-04-09 at 06:23 +0100, Juergen Gross wrote: > On 09.04.2013 04:49, Dario Faggioli wrote: > > as a mechanism of deallocating and reallocating (immediately!) _all_ > > the memory of a domain. Notice it relies on the guest being suspended > > already, before the function is invoked. >=20 > Is this solution intended to be the final one? >=20 Well, the idea of sharing the patches, even at this stage, was right about discussing that! :-P > This might be okay for a domain with less than 1GB of memory, but I see > problems for really huge domains. The needed time to copy the memory migh= t > result in long offline times.=20 > I see what you mean. I thought about approaches that copy only a specific part of the memory, perhaps according to some usage statistics. I've not yet abandoned that idea, but I honestly think that, if we go through the suspend-copy-resume (which is pretty much the only thing I can do with PV guests, isn't it?), that can't be for a page or two, or the impact of the overhead would be even higher! > For this case something like live migration > (optional?) would be a better solution, I think. >=20 Well, I thought about that too, and I'm open to thinking/discussing/hearing suggestions about how to implement a "live phase" for this. The problem is, with a more migration-alike approach, I'll end up doubling the memory requirements of, potentially, all the domains (since I'd need space for storing the full RAM image of each one!), which I don't think it is an acceptable requirement either, _especially_ for big guests, is it? :-( Thanks for you interest, :-) Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-5itek+ExBseMQeyn0vy5 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.13 (GNU/Linux) iEYEABECAAYFAlFju58ACgkQk4XaBE3IOsSAjQCfTRmeEFkjTvJwPMKHVwvuZoy1 cBMAnitJDbvAONAMBchdEhGmlmHB2JdV =PDzH -----END PGP SIGNATURE----- --=-5itek+ExBseMQeyn0vy5-- --===============7847547628211724519== 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 --===============7847547628211724519==--