From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v4 03/15] libxl: introduce libxl_get_nr_cpus() Date: Tue, 3 Dec 2013 19:15:04 +0100 Message-ID: <1386094504.5338.348.camel@Solace> References: <20131122183332.11200.20231.stgit@Solace> <20131122185658.11200.13074.stgit@Solace> <21150.6530.28766.823281@mariner.uk.xensource.com> <1386093157.5338.337.camel@Solace> <21150.6842.156846.991072@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5433349939378337678==" Return-path: In-Reply-To: <21150.6842.156846.991072@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: Marcus Granado , Keir Fraser , Ian Campbell , Li Yechen , George Dunlap , Andrew Cooper , Juergen Gross , xen-devel@lists.xen.org, Jan Beulich , Justin Weaver , Matt Wilson , Elena Ufimtseva List-Id: xen-devel@lists.xenproject.org --===============5433349939378337678== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1G9cxtKeCb9xfzdz/mYk" --=-1G9cxtKeCb9xfzdz/mYk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mar, 2013-12-03 at 17:54 +0000, Ian Jackson wrote: > Dario Faggioli writes ("Re: [PATCH v4 03/15] libxl: introduce libxl_get_n= r_cpus()"): > > On mar, 2013-12-03 at 17:48 +0000, Ian Jackson wrote: > > > This number might be out of date as soon as it is read, won't it ? > >=20 > > Quite possible, yes. > >=20 > > So, are you suggesting that we shouldn't even allow the user to read it= ? > > Or that I should mention that in the comment? (Or something else?) >=20 > Perhaps I didn't explain my concerns clearly enough. >=20 > I wonder what is it for ? Isn't it difficult to use correctly ? >=20 It is indeed. In fact, it is for now used only in the dryrun_only path of the (newly introduced by this series) `xl vcpu-pin' command and, later in the series, for the sake of providing some LOG_DEBUG or LOG_WARN info. Unfortunately, there are not much alternatives to figure out which ones of the bits in a libxl_bitmap (be it a cpumap, in this case) are set to 0 because the pcpu in question is up and running but not part of the mask, or, OTOH, it's just that the map is 64 bits wide, but we only have 8 pcpus. :-/ I really don't think there are better ways to solve this at the libxl layer, and, if we want to improve the situation, we probably should amend the handling (not the API, hopefully) of libxl_bitmap in a more fundamental way. I'm certainly up for it, but perhaps not at this stage in the code freeze :-/ However, again, all this drives is a dryrun_only mode and some debug/warn output, so I really think there is no real harm. On an IRC conversation, IanJ seems to be convinced about this too: Diziet: Eg if you run it while also adding a cpu ? dariof: Diziet: it's in the dry_run path dariof: Diziet: so, when it prints the cpumap that would have been used (if= not in dryrun_only) mode, like this: print_bitmap(cpumap.map, nb_cpu, stdo= ut); dariof: Diziet: it's possible for the output to not be consistent with the = new situation dariof: Diziet: basically, if it asks for the number of onlince cpus, it ge= ts 3, and then the mask is <0111> it will print "all" Diziet: I think you have convinced me that this is too intractable a proble= m to solve at this level of the API and that therefore the call you propose= to add is fine. Diziet: Shall I c&p this scrool into an email with my ack ? I cut-&-paste-d this with Ian's permission, but I'd rather avoid providing a formal "Acked-by: Ian Jackson" line myself! :-P Ian, Please :-) 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) --=-1G9cxtKeCb9xfzdz/mYk 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) iEYEABECAAYFAlKeH6gACgkQk4XaBE3IOsTv9gCglt4g6uaTyXEL6sFgw6ygrwEr zREAnj+7RxGfy1ltyxIFeKmezxlf5IMl =KyJd -----END PGP SIGNATURE----- --=-1G9cxtKeCb9xfzdz/mYk-- --===============5433349939378337678== 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 --===============5433349939378337678==--