[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On lun, 2014-03-10 at 16:39 +0000, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 2/4] libxc: report how much memory a domain 
> has on each NUMA node"):
> > by means of a new interface: xc_domain_numainfo().
> > 
> > The caller is expected to allocate an array for the call to fill,
> > with the results of the XEN_DOMCTL_numainfo hypercall. The size of
> > the array is also passed to the function, which then returns back
> > the number of elements that have actually been filled by Xen.
> Is there a need to get this data in a way which is coherent with the
> domain info list memory usage data ?
You mean the output of `xl list' and `xl list -l'? I mean, these:

root@Zhaman:~# xl list 1
Name                                        ID   Mem VCPUs      State   Time(s)
vm-test                                      1  4096    16     -b----       6.8

root@Zhaman:~# xl list -l 1
            "b_info": {
                "max_memkb": 4194304,
                "target_memkb": 4194304,
                "video_memkb": -1,
                "shadow_memkb": 49152,


If yes, I think it is coherent, and if not, yes, it should be and that's
a bug... have you found any occurrences of such thing?

> What are callers supposed to do about discrepancies between the two
> sets of information ?
I'm sorry, what discrepancies?

root@Zhaman:~# xl numainfo 1
NODE Affinity: all
  Node 0: 2097152 Kb
  Node 1: 2097152 Kb

root@Zhaman:~# bc -l
bc 1.06.95

Or was it something else you where talking about?

> (I forget: is the choice of node to allocate memory from up to the
> guest, or the hose ?  
It's up to the toolstack. Then, something that can happen is that Xen
does not have enough memory on the specified nodes, but that's another

> Is there any way to say a guest can use no more
> than X1 amount on node 1 and no more than X2 on node 2 ?)
There is no now, but that's a nice addition, and there will be soon, as,
for instance, Elena had it implemented already, for the sake of vNUMA
(but it can be used in non-vNUMA contexts too).

Did I answer your questions?

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



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