Re: [PATCH v4 03/15] libxl: introduce libxl_get_nr_cpus()

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1977 bytes --]

`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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel