From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 06 of 11] libxl: introduce libxl_get_numainfo() Date: Thu, 31 May 2012 16:57:26 +0200 Message-ID: <1338476246.15014.41.camel@Solace> References: <5c4b4f0c184fa3534bcb.1338466271@Solace> <20423.32435.342657.764548@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4288905101551213177==" Return-path: In-Reply-To: <20423.32435.342657.764548@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: Andre Przywara , Ian Campbell , Stefano Stabellini , George Dunlap , Juergen Gross , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============4288905101551213177== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-OPbNxE30SYDHsEW0bixZ" --=-OPbNxE30SYDHsEW0bixZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2012-05-31 at 15:22 +0100, Ian Jackson wrote: > Dario Faggioli writes ("[PATCH 06 of 11] libxl: introduce libxl_get_numai= nfo()"): > > Make some NUMA node information available to the toolstack. Achieve > > this by means of xc_numainfo(), which exposes memory size and amount > > of free memory of each node, as well as the relative distances of > > each node to all the others. > ... > > +#define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0) >=20 > Is there some reason we can't just make sure we use the same value for > this in both places ? That would avoid the need for this: >=20 Sorry, with "both places" being? Maybe you're talking about reusing LIBXL_CPUTOPOLOGY_INVALID_ENTRY here as well? If yes, I think it is possible and I also thought doing it like that... Or was it something different you were saying? > > +#define V(mem, i) (mem[i] =3D=3D INVALID_NUMAINFO_ID) ? \ > > + LIBXL_NUMAINFO_INVALID_ENTRY : mem[i] >=20 > I appreciate that the types aren't the same. In libxc it's an > unsigned long. But shouldn't they be the same ? >=20 I again am not sure about what types you are talking about here I'm afraid... :-( > > +libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr) > > +{ > > + xc_numainfo_t ninfo; > > + DECLARE_HYPERCALL_BUFFER(xc_node_to_memsize_t, memsize); > > + DECLARE_HYPERCALL_BUFFER(xc_node_to_memfree_t, memfree); > > + DECLARE_HYPERCALL_BUFFER(uint32_t, node_distances); > > + libxl_numainfo *ret =3D NULL; > > + int i, j, max_nodes; > > + > > + max_nodes =3D libxl_get_max_nodes(ctx); > > + if (max_nodes =3D=3D 0) > > + { > > + LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of NODE= S"); > > + return NULL; > > + } > > + > > + memsize =3D xc_hypercall_buffer_alloc > > + (ctx->xch, memsize, sizeof(*memsize) * max_nodes); > > + memfree =3D xc_hypercall_buffer_alloc > > + (ctx->xch, memfree, sizeof(*memfree) * max_nodes); > > + node_distances =3D xc_hypercall_buffer_alloc > > + (ctx->xch, node_distances, sizeof(*node_distances) * max_nodes= * max_nodes); >=20 > This kind of stuff normally lives in libxc. I appreciate that we have > a bit of it in libxl already, but do we want to perpetuate that ? >=20 Yes, I did this like it is mainly because it is exactly what libxl_get_cpu_topology() does and thus I thought it to be the way to go. :-) > > + ret =3D malloc(sizeof(libxl_numainfo) * max_nodes); > > + if (ret =3D=3D NULL) { >=20 > In libxl you can use libxl__zalloc(NULL,...) (and don't have to check > for errors because it can't fail). But perhaps this is going into > libxc ? >=20 About libxl__zalloc(), noted. Thanks. About moving this all, I can of couse look into doing that, if wanted. > I'd like to hear what other people say about putting this in libxl > vs. libxc. > Sure, just let me know what people prefer... 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) --=-OPbNxE30SYDHsEW0bixZ 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) iEYEABECAAYFAk/HhtYACgkQk4XaBE3IOsQ3wgCbBn/FXWHJdoEIsriiQ2dJIq/a 5scAoJ0elnxcY1kbXsjXkwXqUvagiLWQ =755N -----END PGP SIGNATURE----- --=-OPbNxE30SYDHsEW0bixZ-- --===============4288905101551213177== 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 --===============4288905101551213177==--