From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Proposed new "memory capacity claim" hypercall/feature Date: Thu, 01 Nov 2012 03:13:21 +0100 Message-ID: <1351736001.18330.139.camel@Solace> References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default> <20121029223555.GA24388@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0208552959545569884==" Return-path: In-Reply-To: <20121029223555.GA24388@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 , "Keir (Xen.org)" , Ian Campbell , Konrad Wilk , George Dunlap , Kurt Hackel , George Shuklin , Olaf Hering , xen-devel@lists.xen.org, Zhigang Wang , Ian Jackson List-Id: xen-devel@lists.xenproject.org --===============0208552959545569884== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-jrQPAMTpPwECh/tIGrmE" --=-jrQPAMTpPwECh/tIGrmE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2012-10-29 at 22:35 +0000, Tim Deegan wrote: > At 10:06 -0700 on 29 Oct (1351505175), Dan Magenheimer wrote: > > In the case of a dying domain, a XENMEM_release operation > > is implied and must be executed by the hypervisor. > >=20 > > Ideally, the quantity of unclaimed memory for each domain and > > for the system should be query-able. This may require additional > > memory_op hypercalls. > >=20 > > I'd very much appreciate feedback on this proposed design! >=20 > As I said, I'm not opposed to this, though even after reading through > the other thread I'm not convinced that it's necessary (except in cases > where guest-controlled operations are allowed to consume unbounded > memory, which frankly gives me the heebie-jeebies). >=20 Let me also ask something. Playing with NUMA systems I've been in the situation where it would be nice to know not only how much free memory we have in general, but how much free memory there is in a specific (set of) node(s), and that in many places, from the hypervisor, to libxc, to top level toolstack. Right now I ask this to Xen, but that is indeed prone to races and TOCTOU issues if we allow for domain creation and ballooning (tmem/paging/...) to happen concurrently between themselves and between each other (as noted in the long thread that preceded this one). Question is, the "claim" mechanism you're proposing is by no means NUMA node-aware, right? 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) --=-jrQPAMTpPwECh/tIGrmE 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) iEYEABECAAYFAlCR2sEACgkQk4XaBE3IOsRsfQCfbb/6tuBlKmKCmEokERwH2Tja gNAAoKKG2iiMHTey7J1N85ONU7Mq0sjS =ynoL -----END PGP SIGNATURE----- --=-jrQPAMTpPwECh/tIGrmE-- --===============0208552959545569884== 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 --===============0208552959545569884==--