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

Re: [Xen-devel] [PATCH 03/11] [XEN] NUMA guest tools interface


  • To: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
  • From: Dulloor <dulloor@xxxxxxxxx>
  • Date: Fri, 9 Apr 2010 01:14:19 -0400
  • Cc: Andre Przywara <andre.przywara@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 08 Apr 2010 22:15:09 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kWZSkPcVH0YxEE68qGqHrFDEwhny86R4fSzCz5GfYnqGfPlqlIQmCOgI3mTqg9PV0d CkqYJHo5LXI5/yuk4nt+CKIz2e4H/8088pkPwtZYPeskQdWmMT9s1tVTbBRs4Dl723Xc avKHIYwM3UcUKbsKMGjPdTn0TFG9gaZHtAuD4=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On Wed, Apr 7, 2010 at 10:52 AM, Cui, Dexuan <dexuan.cui@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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