[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 03/15] libxl: introduce libxl_get_nr_cpus()
`On mar, 2013-12-03 at 13:17 -0500, Konrad Rzeszutek Wilk wrote: > On Tue, Dec 03, 2013 at 06:09:10PM +0000, George Dunlap wrote: > > On 12/03/2013 05:54 PM, Ian Jackson wrote: > > >Dario Faggioli writes ("Re: [PATCH v4 03/15] libxl: introduce > > >libxl_get_nr_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 ? > > >> > > >>Quite possible, yes. > > >> > > >>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?) > > > > > >Perhaps I didn't explain my concerns clearly enough. > > > > > >I wonder what is it for ? Isn't it difficult to use correctly ? > > > > Dario uses it in the new version of libxl_vcpu_set_affinity() to > > limit what was considered an "unreachable cpu" in its warning. (v5 > > 14/17) That is, if you set the affinity to > > 1111111111111111111111..., and there are only 4 pcpus, it will > > return 111100000..... These don't match, and yet there are no > > unreachable cpus. So it asks nr_cpus first, then only compares bits > > 1..[nr_cpus-1]. > > What about the inverse? 2 PCPUs and 16 VCPUS? Won't that still throw > this calculation off? > It's not how it works, it's not the number of vcpus against pcpus that matters. So, as soon as your 16 vcpus have affinity with some _real_, _existing_ and _online_ pcpus, that would be fine and this situation you're mentioning won't cause any problem. OTOH, if you offline any of the pcpus in the process, no matter how many pcpus-vs-vcpus you have, you risk getting a spurious warning (and only that). Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |