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: Mon, 6 May 2013 19:37:38 +0200 Message-ID: <1367861858.2958.86.camel@Solace> References: <20130502143209.GL65547@ocelot.phlegethon.org> <51828122.7000900@eu.citrix.com> <20130502151305.GN65547@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3053236342917824366==" Return-path: In-Reply-To: <20130502151305.GN65547@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: Dan Magenheimer , Ian Campbell , George Dunlap , Andrew Cooper , Juergen Gross , Olaf Hering , xen-devel , David Vrabel , Keir Fraser , Andres Lagar-Cavilla , Jan Beulich , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org --===============3053236342917824366== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LJ0Cz95RXlDAWcyweuZv" --=-LJ0Cz95RXlDAWcyweuZv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On gio, 2013-05-02 at 16:13 +0100, Tim Deegan wrote: > At 16:07 +0100 on 02 May (1367510834), George Dunlap wrote: > > > Hmm -- isn't it the case that if there is not *free* memory lying aroun= d=20 > > somewhere, then this operation is fairly pointless? What will happen i= s=20 > > that after freeing batch 0, "allocate new batch 1" will get that=20 > > memory. So copying it to a temporary buffer in dom0 seems like not a= =20 > > particularly useful thing to do -- it should try to allocate a new=20 > > buffer to copy into directly, and if that fails, just say "No point=20 > > trying -- no empty memory to move into." >=20 George, good point, checking for free memory is something I did not think about, but it's necessary for this while thing to be meaningful. This could be tricky to do in the right way, due to the well known races we have when dealing with memory at the toolstack level, but I'll give it a thought, thanks. :-) However... > Sure, that's better, as long as the temporary bump in the VM's max_pages > is acceptable to the rest of the toolstack. :) >=20 ... This that Tim is saying is the main reason I'm going through a temporary buffer in Dom0: I can't be sure that, if failing allocating more memory for the domain before freeing it, that comes from the host being actually out-of-memory, or from the fact that I'm hitting max_pages. That's why I went for the "deallocate first" approach. I can investigate what temporarily bumping the page limit could mean, but I think I like what Tim proposed in his first e-mail better... Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-LJ0Cz95RXlDAWcyweuZv 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) iEYEABECAAYFAlGH6mIACgkQk4XaBE3IOsR/VQCfYHpISdp7VS83D980Iy9+Pc32 kRsAniaKdwFKsctRRnG9LHsX4xquAHok =pxfS -----END PGP SIGNATURE----- --=-LJ0Cz95RXlDAWcyweuZv-- --===============3053236342917824366== 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 --===============3053236342917824366==--