From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v3 11/14] libxl: get and set soft affinity Date: Wed, 20 Nov 2013 15:50:30 +0100 Message-ID: <1384959030.15360.85.camel@Solace> References: <20131118175544.31002.79574.stgit@Solace> <20131118181813.31002.61195.stgit@Solace> <1384881864.16252.48.camel@hastur.hellion.org.uk> <1384883478.19880.170.camel@Abyss> <1384946825.28441.56.camel@kazak.uk.xensource.com> <1384948800.15360.65.camel@Solace> <1384949152.28441.65.camel@kazak.uk.xensource.com> <1384949887.15360.78.camel@Solace> <1384950382.6071.3.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1613899688607618303==" Return-path: In-Reply-To: <1384950382.6071.3.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: Marcus Granado , Keir Fraser , Matt Wilson , Li Yechen , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , xen-devel@lists.xen.org, Jan Beulich , Justin Weaver , Elena Ufimtseva List-Id: xen-devel@lists.xenproject.org --===============1613899688607618303== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Xtt/CUSG8d3YwwfSTcWh" --=-Xtt/CUSG8d3YwwfSTcWh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mer, 2013-11-20 at 12:26 +0000, Ian Campbell wrote: > On Wed, 2013-11-20 at 13:18 +0100, Dario Faggioli wrote: > > After going down to Xen and then back from there, i.e., what happens to > > ecpumap, the "all" from above has become, again on my system, where I > > have 16 cpus, something like "0-15". That is, looking at the bits in th= e > > actual uint, the first 16 of them to 1, the other to 0. >=20 > And the returned bitmap doesn't have a size =3D=3D 16? That's not very > helpful I suppose. >=20 Where? I mean what size are you talking about? In libxl, it is libxl itself that allocates the bitmap and decides, at allocation time (with the third parameter of libxl_cpu_bitmap_alloc()) how many bits I want there, and nothing changes that. So, after having allocated a cpumap 64 bits big, there is no way it can tell that only 16 are worth. I can allocate the cpumap more precisely but, for one, that would still require figuring out the actual number of pcpus. Also, that would work for 16, but for any other value that is not multiple of sizeof(uint8_t), I'd have to face the same problem. > It seems like it should be quite quick to wire up xc_get_nr_cpus based > on xc_get_max_cpus and use that. >=20 No it's not. On it. > Is there not a race condition here somewhere -- what happens if a CPU is > on/offlined during all this? >=20 Again, I'm not getting. What's the window where you're worried about races, if on/offlining is involved? What do you refer to with "during all this" ? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-Xtt/CUSG8d3YwwfSTcWh 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.15 (GNU/Linux) iEYEABECAAYFAlKMzDYACgkQk4XaBE3IOsTGagCfbegasO2WPCQCv2x5qKv+Xwnc /yMAoJTD6mpF5YhqpcFd/Uog36Zcv/24 =W0Rv -----END PGP SIGNATURE----- --=-Xtt/CUSG8d3YwwfSTcWh-- --===============1613899688607618303== 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 --===============1613899688607618303==--