xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

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