From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 2/4] libxc: report how much memory a domain has on each NUMA node Date: Mon, 10 Mar 2014 18:07:30 +0100 Message-ID: <1394471250.17832.11.camel@Solace> References: <20140305143357.6984.7729.stgit@Solace> <20140305143635.6984.34422.stgit@Solace> <21277.60093.406016.679465@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3779470395813138625==" Return-path: In-Reply-To: <21277.60093.406016.679465@mariner.uk.xensource.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: Ian Jackson Cc: Ian Campbell , Andrew Cooper , Juergen Gross , xen-devel , Jan Beulich , Daniel De Graaf List-Id: xen-devel@lists.xenproject.org --===============3779470395813138625== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4zmQqMmKYHrzkuePenhU" --=-4zmQqMmKYHrzkuePenhU Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On lun, 2014-03-10 at 16:39 +0000, Ian Jackson wrote: > Dario Faggioli writes ("[PATCH 2/4] libxc: report how much memory a domai= n has on each NUMA node"): > > by means of a new interface: xc_domain_numainfo(). > >=20 > > The caller is expected to allocate an array for the call to fill, > > with the results of the XEN_DOMCTL_numainfo hypercall. The size of > > the array is also passed to the function, which then returns back > > the number of elements that have actually been filled by Xen. >=20 > Is there a need to get this data in a way which is coherent with the > domain info list memory usage data ? >=20 You mean the output of `xl list' and `xl list -l'? I mean, these: root@Zhaman:~# xl list 1 Name ID Mem VCPUs State Time(s) vm-test 1 4096 16 -b---- = 6.8 root@Zhaman:~# xl list -l 1 [ ... "b_info": { ... "max_memkb": 4194304, "target_memkb": 4194304, "video_memkb": -1, "shadow_memkb": 49152, ... ] ? If yes, I think it is coherent, and if not, yes, it should be and that's a bug... have you found any occurrences of such thing? > What are callers supposed to do about discrepancies between the two > sets of information ? > I'm sorry, what discrepancies? root@Zhaman:~# xl numainfo 1 NODE Affinity: all Memory: Node 0: 2097152 Kb Node 1: 2097152 Kb root@Zhaman:~# bc -l bc 1.06.95 2097152+2097152 4194304 Or was it something else you where talking about? > (I forget: is the choice of node to allocate memory from up to the > guest, or the hose ? =20 > It's up to the toolstack. Then, something that can happen is that Xen does not have enough memory on the specified nodes, but that's another story. > Is there any way to say a guest can use no more > than X1 amount on node 1 and no more than X2 on node 2 ?) >=20 There is no now, but that's a nice addition, and there will be soon, as, for instance, Elena had it implemented already, for the sake of vNUMA (but it can be used in non-vNUMA contexts too). Did I answer your questions? Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-4zmQqMmKYHrzkuePenhU 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 v2.0.22 (GNU/Linux) iEYEABECAAYFAlMd8VIACgkQk4XaBE3IOsRieACeNvF2O9htgtNHctjWVtG+Fmcp V9UAnizME74Oo4gQP2FLL6q4/o2hwJBj =v7hD -----END PGP SIGNATURE----- --=-4zmQqMmKYHrzkuePenhU-- --===============3779470395813138625== 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 --===============3779470395813138625==--