Re: [PATCH v3 11/14] libxl: get and set soft affinity

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

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

On mer, 2013-11-20 at 12:05 +0000, Ian Campbell wrote:
> On Wed, 2013-11-20 at 13:00 +0100, Dario Faggioli wrote:
> > I'll keep looking but, in case I really don't fine anything, do you want
> > me to:
> >  - stick with this, at least for now;
> >  - introduce a new libxl (and probably libxc too) interface for this
> 
> I don't understand why libxl_get_max_cpus, which is certainly at least
> as big as you need, isn't sufficient here. Especially since in the same
> function you call libxl_cpu_bitmap_alloc(...,..., 0) which uses
> libxl_get_max_cpus.
> 
As a matter of fact, it's _too_ big!

The point here is that, whenever the caller gives me a cpumap that comes
from him specifying "all" in the config file, this cpumap is, for
instance, on my system, and unsigned int full of 1-s. If you manage to
(pretty) print it, that would look like "0-63".

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 the
actual uint, the first 16 of them to 1, the other to 0.

Well, what I want is to be able to _not_ warn the user in this case,
since he asked for all the cpus, and that's what he's getting, but for
doing that I need to be able to restrict the comparison that is
happening in libxl_bitmap_equal() to *only* the actual number of cpus,
not the theoretically supported one.

> You then use this with "libxl_bitmap_equal(cpumap, &ecpumap, nr_cpus)"
> where surely the sizes of cpumap and ecpumap could be used and/or are
> what actually matter? (and shouldn't you be checking that the sizes meet
> some constraint relative to each other?)
> 
Fair enough. It's very unlikely, but yes, since the interface allows to
define bitmaps of different sizes, I should probably check that. Good
point actually, but unrelated to and unhelpful to solve my issue.

Thanks and 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