From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v9 9/9] libxl: automatic NUMA placement affects soft affinity Date: Thu, 19 Jun 2014 19:33:50 +0200 Message-ID: <1403199230.12893.20.camel@Solace> References: <20140618141449.21586.55528.stgit@Solace> <20140618142849.21586.23269.stgit@Solace> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0879533648943520348==" Return-path: In-Reply-To: <20140618142849.21586.23269.stgit@Solace> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org Cc: Ian.Jackson@citrix.com, George.Dunlap@citrix.com, Wei Liu , Ian.Campbell@citrix.com, Andrew.Cooper3@citrix.com List-Id: xen-devel@lists.xenproject.org --===============0879533648943520348== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-w6N9g+0WO+5HvTKqWYPO" --=-w6N9g+0WO+5HvTKqWYPO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable BTW, I've got a question about libxl cleanup/garbage collection, etc. So, in the code below: On mer, 2014-06-18 at 16:28 +0200, Dario Faggioli wrote: > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c > index 4a52da1..58f46e3 100644 > --- a/tools/libxl/libxl_dom.c > +++ b/tools/libxl/libxl_dom.c > @@ -248,18 +248,44 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid, > * some weird error manifests) the subsequent call to > * libxl_domain_set_nodeaffinity() will do the actual placement, > * whatever that turns out to be. > > if (libxl_defbool_val(info->numa_placement)) { > + libxl_bitmap cpumap_soft; > + > + /* We require both hard and soft affinity not to be set */ > if (!libxl_bitmap_is_full(&info->cpumap) || > - info->num_vcpu_hard_affinity) { > + info->num_vcpu_hard_affinity || info->num_vcpu_soft_affinity= ) { > LOG(ERROR, "Can run NUMA placement only if no vcpu " > - "affinity is specified"); > + "(hard or soft) affinity is specified"); > return ERROR_INVAL; > } > =20 > - rc =3D numa_place_domain(gc, domid, info); > + rc =3D libxl_cpu_bitmap_alloc(ctx, &cpumap_soft, 0); > if (rc) > return rc; > + > + rc =3D numa_place_domain(gc, domid, info); > + if (rc) { > + libxl_bitmap_dispose(&cpumap_soft); > + return rc; > + } > + > Do I need this call to libxl_bitmap_dispose(), to avoid leaking what libxl_cpu_bitmap_alloc() did upon return, or does libxl cleans this up for me? :-) As you can see, I'm talking about the case where I'm inside libxl (i.e., within libxl__build_pre() ) 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) --=-w6N9g+0WO+5HvTKqWYPO 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) iEYEABECAAYFAlOjHv4ACgkQk4XaBE3IOsQ7pgCgos/EolSKHMbFOFLJrUT9nNZD jr8An30XN6TXTSUSKxEi5+NsB6pGvwrR =gXjD -----END PGP SIGNATURE----- --=-w6N9g+0WO+5HvTKqWYPO-- --===============0879533648943520348== 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 --===============0879533648943520348==--