[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 17:54 +0000, 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 ?
> 
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, stdout);
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 gets 
3, and then the mask is <0111> it will print "all"
Diziet: I think you have convinced me that this is too intractable a problem 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

-- 
<<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
Description: This is a digitally signed message part

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.