Re: [Xen-devel] [PATCH 3/4] libxl: report how much memory a domain has on each NUMA node

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 3/4] libxl: report how much 
memory a domain has on each NUMA node"):
> On lun, 2014-03-10 at 16:40 +0000, Ian Jackson wrote:
> > Is there some reason this shouldn't be in the normal domain info
> > struct ?
> 
> Nothing other than personal taste. For consistency with getting/setting
> node affinity, I introduced a call to retrieve this, and specifically.
> Having done that, I decided to use an independent struct also.

I see.  Is there a performance reason to have it in a separate struct,
or a race coherency reason to have it in the same one ?

> There is no harm in moving it somewhere else, if you like that better.

I want to know that there's a reason :-).  (Or at least, that there is
no reason not to do it this way - which implies having tried to think
of pros and cons).

> Just to be sure, you mean putting it in here:
> libxl_dominfo = Struct("dominfo",[

> and retrieving by calling libxl_list_domain, right?

Right.

> In which case, I don't think it will be that easy to have a function
> that retrieves specifically  this information (and whatever else we
> could be wanting to stash in a libxl_domain_numainfo, type... Do you see
> any issue in dropping it? (The problem, of course, won't be the
> function, but what to return from it, if I decide not to introduce an
> ad-hoc type).

I'm afraid I don't understand this paragraph at all.  Can you make it
less abstract ?  I'm getting confused by all the "this" and "that"s, I
think.

Ian.

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