Xen devel - Apr 2010 - [PATCH 03/11] [XEN] NUMA guest tools interface

The patch adds hypercall interfaces to get/set the virtual numa layout
for a domain.

-dulloor

Signed-off-by: Dulloor Rao <dulloor@gatech.edu>


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

Dulloor wrote:
> The patch adds hypercall interfaces to get/set the virtual numa layout
> for a domain.
I don''t see the need for introducing this many new interfaces. I 
couldn''t find a reference for the nodemap information (mfn_to_nid) to
be
actually used somewhere, is there any missing part or was it just for 
the sake of completeness?
Beside that, cpu_to_node is already in physinfo, and via xc_availheap 
(which takes a node parameter) you can query the amount of free memory 
per node. I think that is all we need to know about the host''s NUMA 
topology, but correct me if I am wrong.
(OK, the distance information is missing...)
 From a design point of view I would avoid exporting so many host 
machine information to Dom0 unless we really need it.

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12


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

Andre Przywara wrote:
> Dulloor wrote:
>> The patch adds hypercall interfaces to get/set the virtual numa
>> layout for a domain.
> I don''t see the need for introducing this many new interfaces. I
I also have the same feeling. :-)
> couldn''t find a reference for the nodemap information (mfn_to_nid)
to
> be actually used somewhere, is there any missing part or was it just
> for the sake of completeness?
> Beside that, cpu_to_node is already in physinfo, and via xc_availheap
> (which takes a node parameter) you can query the amount of free memory
> per node. I think that is all we need to know about the host''s
NUMA
> topology, but correct me if I am wrong.
> (OK, the distance information is missing...)
I''d like to have Nitin''s patch:
http://old.nabble.com/Host-Numa-informtion-in-dom0-td27379527.html.
>  From a design point of view I would avoid exporting so many host
> machine information to Dom0 unless we really need it.
Agree. I think we should have a fundamental and brief API to export the
necessary info.

Thanks,
-- Dexuan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 07/04/2010 15:52, "Cui, Dexuan" <dexuan.cui@intel.com> wrote:
>> couldn''t find a reference for the nodemap information
(mfn_to_nid) to
>> be actually used somewhere, is there any missing part or was it just
>> for the sake of completeness?
>> Beside that, cpu_to_node is already in physinfo, and via xc_availheap
>> (which takes a node parameter) you can query the amount of free memory
>> per node. I think that is all we need to know about the host''s
NUMA
>> topology, but correct me if I am wrong.
>> (OK, the distance information is missing...)
> I''d like to have Nitin''s patch:
> http://old.nabble.com/Host-Numa-informtion-in-dom0-td27379527.html.
Now applied as xen-unstable:21118.

 -- Keir



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

On Wed, Apr 7, 2010 at 8:13 AM, Andre Przywara <andre.przywara@amd.com>
wrote:
> Dulloor wrote:
>>
>> The patch adds hypercall interfaces to get/set the virtual numa layout
>> for a domain.
>
> I don''t see the need for introducing this many new interfaces. I
couldn''t
> find a reference for the nodemap information (mfn_to_nid) to be actually
> used somewhere, is there any missing part or was it just for the sake of
> completeness?
The nodemap information is right now a place holder. The part is used in the
implementation of enlightened ballooning, which is essential for NUMA
guests that
could increase/decrease/exchange memory reservations. I will spin out
a refreshed
patch for this in a couple of days.
> Beside that, cpu_to_node is already in physinfo, and via xc_availheap
(which
> takes a node parameter) you can query the amount of free memory per node. I
> think that is all we need to know about the host''s NUMA topology,
but
> correct me if I am wrong.
> (OK, the distance information is missing...)
I wanted to have all the desired node information (size, free memory,
node_to_cpu masks, distances) in a single place. But, I could have
constructed this without adding a new interface too.
> From a design point of view I would avoid exporting so many host machine
> information to Dom0 unless we really need it.
I agree. I am exporting only the information that is essential and
which makes design sense.
>
> Regards,
> Andre.
>
> --
> Andre Przywara
> AMD-Operating System Research Center (OSRC), Dresden, Germany
> Tel: +49 351 448-3567-12
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Apr 7, 2010 at 10:52 AM, Cui, Dexuan <dexuan.cui@intel.com>
wrote:
> Andre Przywara wrote:
>> Dulloor wrote:
>>> The patch adds hypercall interfaces to get/set the virtual numa
>>> layout for a domain.
>> I don''t see the need for introducing this many new interfaces.
I
> I also have the same feeling. :-)
>
>> couldn''t find a reference for the nodemap information
(mfn_to_nid) to
>> be actually used somewhere, is there any missing part or was it just
>> for the sake of completeness?
>> Beside that, cpu_to_node is already in physinfo, and via xc_availheap
>> (which takes a node parameter) you can query the amount of free memory
>> per node. I think that is all we need to know about the host''s
NUMA
>> topology, but correct me if I am wrong.
>> (OK, the distance information is missing...)
> I''d like to have Nitin''s patch:
http://old.nabble.com/Host-Numa-informtion-in-dom0-td27379527.html.
As I mentioned in earlier mail, I wanted to have all the desired node
information (size, free memory,
node_to_cpu masks, distances) in a single place. Also, I somewhat
dislike the existing interface for two reasons :
1) having to pass pointers to arrays (like cpu_to_node_arr), when all
we need are simple cpu-bitmasks, for which we already have the
xenctl_cpumap structure.
2) placeholders for (controversial ?) parameters like cpu_to_socket,
which we surely don''t need. The existing interface is overloaded with
information we don''t need for our use.
>
>>  From a design point of view I would avoid exporting so many host
>> machine information to Dom0 unless we really need it.
> Agree. I think we should have a fundamental and brief API to export the
necessary info.
With the XENMEM_numa_op, I was shooting for such a fundamental and
(equally importantly) brief API.

However, I don''t have a very strong preference and I can construct the
information from Nitin''s patch too, if you think that one sub-command
is such a lot of duplication. Please let me know.
>
> Thanks,
> -- Dexuan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel