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 17:27:25 +0100 Message-ID: <1384964845.10582.12.camel@Abyss> 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> <1384959030.15360.85.camel@Solace> <1384959360.6071.70.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2434858646371727597==" Return-path: In-Reply-To: <1384959360.6071.70.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 --===============2434858646371727597== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-n/e9gfxAu+D+QLaHiGbz" --=-n/e9gfxAu+D+QLaHiGbz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mer, 2013-11-20 at 14:56 +0000, Ian Campbell wrote: > On Wed, 2013-11-20 at 15:50 +0100, Dario Faggioli wrote: > > 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" ? >=20 > Between getting the maximum cpu number and checking the results of a pin > call. What happens if a CPU went away such that you think when checking > that there is 16 cpus (based on old information) but when the pin > hypercall was made there were only 15. Or conversely if a CPU was > plugged in. >=20 Well, for the sake of this patch, all that we risk is printing a spurious warning or missing one. Anyway, I see what you mean now, and I guess I can try to mitigate it, by moving the check for the number of cpus after the affinity setting call. That would at least make it more likely for the information about the number of cpus to be consistent with the result of the call, but won't eliminate the possibility of races. In fact, I don't think I can't avoid that with 100% probability, as there is no way to get both the result of the affinity setting call and the number of cpus in an atomic way, and I don't think it's worth introducing one for the sake of this... > Also, does this check fail if the cpumask is sparse? Is that something > which can happen e.g. unplugging CPU#8 in a 16 CPU system? >=20 Well, in that case I guess it'd be fine to print the warning. I mean, if the user wanted affinity to cpu#8 and that went away, it's a good to tell him he's not getting (exactly) what he asked, isn't it? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-n/e9gfxAu+D+QLaHiGbz 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) iEYEABECAAYFAlKM4u0ACgkQk4XaBE3IOsTqhQCgl6uFUT4ndBpwCURliVdE8lby hlwAnRHR/ULY0CsGCau0tX/vRBwhFHIE =/o1+ -----END PGP SIGNATURE----- --=-n/e9gfxAu+D+QLaHiGbz-- --===============2434858646371727597== 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 --===============2434858646371727597==--