From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 3/4] libxl: report how much memory a domain has on each NUMA node Date: Mon, 10 Mar 2014 18:28:12 +0100 Message-ID: <1394472492.17832.24.camel@Solace> References: <20140305143357.6984.7729.stgit@Solace> <20140305143644.6984.6243.stgit@Solace> <21277.60129.541655.745154@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3240037242647964059==" Return-path: In-Reply-To: <21277.60129.541655.745154@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 --===============3240037242647964059== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-a8ofm3K+oBcSCSNZlNyF" --=-a8ofm3K+oBcSCSNZlNyF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On lun, 2014-03-10 at 16:40 +0000, Ian Jackson wrote: > Dario Faggioli writes ("[PATCH 3/4] libxl: report how much memory a domai= n has on each NUMA node"): > > by calling xc_domain_numainfo(). A new data type, libxl_domain_numainfo > > is being introduced. For now it only holds how much memory a domain has > > allocated on each NUMA node, but it can be useful for, in future, > > reporting more per-domain NUMA related information. >=20 > Is there some reason this shouldn't be in the normal domain info > struct ? >=20 Nothing other than personal taste. For consistency with getting/setting node affinity, I introduced a call to retrieve this, and specifically. Having done that, I decided to use an independent struct also. There is no harm in moving it somewhere else, if you like that better. Just to be sure, you mean putting it in here: libxl_dominfo =3D Struct("dominfo",[ ("uuid", libxl_uuid), ("domid", libxl_domid), ("ssidref", uint32), ("running", bool), ("blocked", bool), ("paused", bool), ("shutdown", bool), ("dying", bool), =20 # Valid iff (shutdown||dying). #=20 # Otherwise set to a value guaranteed not to clash with any valid # LIBXL_SHUTDOWN_REASON_* constant. ("shutdown_reason", libxl_shutdown_reason), ("outstanding_memkb", MemKB), ("current_memkb", MemKB), ("shared_memkb", MemKB), ("paged_memkb", MemKB), ("max_memkb", MemKB), ("cpu_time", uint64), ("vcpu_max_id", uint32), =20 ("vcpu_online", uint32), =20 ("cpupool", uint32), ("domain_type", libxl_domain_type), ], dir=3DDIR_OUT)=20 and retrieving by calling libxl_list_domain, right? In which case, I don't think it will be that easy to have a function that retrieves specifically this information (and whatever else we could be wanting to stash in a libxl_domain_numainfo, type... Do you see any issue in dropping it? (The problem, of course, won't be the function, but what to return from it, if I decide not to introduce an ad-hoc type). 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) --=-a8ofm3K+oBcSCSNZlNyF 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) iEYEABECAAYFAlMd9iwACgkQk4XaBE3IOsRtEQCgnSyELL5qwNYczVPWloo4HRcR X58An2IeoqTig7gdccRphYEqPh2Ynx7v =ddLU -----END PGP SIGNATURE----- --=-a8ofm3K+oBcSCSNZlNyF-- --===============3240037242647964059== 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 --===============3240037242647964059==--