Re: [Xen-devel] [PATCH] xend: Fix non-contiguous NUMA node assignment

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

nr_nodes was always num_online_nodes() returned by Xen -- not accounting for
holes in node id space. Hance I emulated that behaviour from the Python
extension package. If what you actually want everywhere in the Python code
is max_node_id, then please remove the nr_nodes code from xc.c and all
references to it from the Python code. I agree that using max_node_id seems
more correct than nr_nodes -- the intention was for someone to plumb that
new field properly into the Python code anyway.

 -- Keir

On 15/01/2010 13:28, "Andre Przywara" <andre.przywara@xxxxxxx> wrote:

> Hi,
> 
> it seems that I missed a point in this whole addition of max_node_id. I
> see the difference in the Xen HV part, so nr_nodes got replaced with
> max_node_id in physinfo_t (and xc_physinfo_t, respectively).
> But where does this value help in xend? There is no single Python
> reference to the physinfo()'s max_node_id field, instead all functions
> use the old (but now bogus) nr_nodes variable.
> So in the attached patch I kept the xc.physinfo() returned dictionary
> with only a nr_nodes field, calculated by simply adding 1 to max_node_id
> from libxc. Empty nodes can (and will) be detected by iterating through
> the node_to_cpus and node_to_memory lists.
> Nodes without memory should not be considered during guest's memory
> allocation, but will be used for further CPU affinity setting if the
> number of VCPUs exceeds the number of cores per node.
> 
> Please correct me if I am totally wrong on this, but this seems to work
> much better in my case.
> 
> Regards,
> Andre.
> 
> Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel