From: Dulloor <dulloor@gmail.com>
To: "Cui, Dexuan" <dexuan.cui@intel.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH 03/11] [XEN] NUMA guest tools interface
Date: Fri, 9 Apr 2010 01:14:19 -0400 [thread overview]
Message-ID: <x2v940bcfd21004082214za40e7873hadd340c98197ebd1@mail.gmail.com> (raw)
In-Reply-To: <ED3036A092A28F4C91B0B4360DD128EABE1D6672@shzsmsx502.ccr.corp.intel.com>
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
next prev parent reply other threads:[~2010-04-09 5:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-04 19:30 [PATCH 03/11] [XEN] NUMA guest tools interface Dulloor
2010-04-07 12:13 ` Andre Przywara
2010-04-07 14:52 ` Cui, Dexuan
2010-04-07 15:22 ` Keir Fraser
2010-04-09 5:14 ` Dulloor [this message]
2010-04-09 4:58 ` Dulloor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x2v940bcfd21004082214za40e7873hadd340c98197ebd1@mail.gmail.com \
--to=dulloor@gmail.com \
--cc=andre.przywara@amd.com \
--cc=dexuan.cui@intel.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).