From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v9 5/9] libxl/xl: push VCPU affinity pinning down to libxl Date: Wed, 18 Jun 2014 19:00:55 +0200 Message-ID: <1403110855.21681.35.camel@Solace> References: <20140618141449.21586.55528.stgit@Solace> <20140618142818.21586.48020.stgit@Solace> <1403106254.6568.94.camel@kazak.uk.xensource.com> <1403109160.21681.22.camel@Solace> <1403109984.9627.8.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3291844768080390182==" Return-path: In-Reply-To: <1403109984.9627.8.camel@kazak.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 Campbell Cc: Ian.Jackson@citrix.com, Andrew.Cooper3@citrix.com, Wei Liu , George.Dunlap@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============3291844768080390182== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vQeJ9oGwgvKGCzxVoeRi" --=-vQeJ9oGwgvKGCzxVoeRi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mer, 2014-06-18 at 17:46 +0100, Ian Campbell wrote: > On Wed, 2014-06-18 at 18:32 +0200, Dario Faggioli wrote: >=20 > > > > + * The number of libxl_bitmap in the array equals to the maximum n= umber > > > > + * of VCPUs. The size of each bitmap is computed basing on the max= imum > > > > + * number of PCPUs. > > >=20 > > > These are all things which the caller is expect to arrange by making > > > appropriately sized allocations, not inherent properties of the API, = I > > > think. > > >=20 > > > So "the number of libxl_bitmap in the array *should* be equal". "The > > > size of each bitmap should ..." etc. > > >=20 > > Will fix. I will also add a check that this is actually what we get fro= m > > the caller in libxl_dom.c (where the arrays are consumed). >=20 > Or define what will happen if the array is too short of the bitmaps not > size appropriately. >=20 > I think it would be find to only pin the first N cpus for which an array > entry is present and leave the rest floating, and likewise to simply > assume any pcpus past the end of the bitmap are =3D=3D 0. >=20 Sure. It's a bit trickier then to deal with both arrays (hard and soft) at the same time, but it's probably worth a try. 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) --=-vQeJ9oGwgvKGCzxVoeRi 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) iEYEABECAAYFAlOhxccACgkQk4XaBE3IOsRTOgCeJ0lHfR9mDePF6IwQ1deCo/ZI uEEAoIA5tSJXtvsaeM7NHoGGdi5A7l1S =IECo -----END PGP SIGNATURE----- --=-vQeJ9oGwgvKGCzxVoeRi-- --===============3291844768080390182== 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 --===============3291844768080390182==--