[PATCH]pcpu tuples [was Re: [Xen-devel] Xen 3.4.1 NUMA support]

[PATCH]pcpu tuples [was Re: [Xen-devel] Xen 3.4.1 NUMA support]

[Dulloor]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

Attached is a patch to construct pcpu tuples of the form
(node.socket.core.thread), and (currently)used by xm vcpu-pin utility.

-dulloor

On Fri, Nov 13, 2009 at 11:02 AM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> On 13/11/2009 15:40, "Ian Pratt" <Ian.Pratt@eu.citrix.com> wrote:
>
>>> Even better would be to have pCPUs addressable and listable explicitly as
>>> dotted tuples. That can be implemented entirely within the toolstack, and
>>> could even allow wildcarding of tuple components to efficiently express
>>> cpumasks.
>>
>> Yes, I'd certainly like to see the toolstack support dotted tuple notation.
>>
>> However, I just don't trust the toolstack to get this right unless xen has
>> already set it up nicely for it with a sensible enumeration and defined
>> sockets-per-node, cores-per-socket and threads-per-core parameters. Xen should
>> provide a clean interface to the toolstack in this respect.
>
> Xen provides a topology-interrogation hypercall which should suffice for
> tools to build up a {node,socket,core,thread}<->cpuid mapping table.
>
>  -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

[-- Attachment #2: pcpu-tuple.patch --]
[-- Type: text/x-diff, Size: 9829 bytes --]

diff -r b6b2e97f8db9 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c	Fri Nov 13 22:13:59 2009 +0000
+++ b/tools/python/xen/lowlevel/xc/xc.c	Tue Nov 17 01:48:24 2009 -0500
@@ -1054,15 +1054,21 @@
 static PyObject *pyxc_physinfo(XcObject *self)
 {
 #define MAX_CPU_ID 255
-    xc_physinfo_t info;
+    xc_physinfo_t info = { 0 };
     char cpu_cap[128], virt_caps[128], *p;
     int i, j, max_cpu_id;
     uint64_t free_heap;
     PyObject *ret_obj, *node_to_cpu_obj, *node_to_memory_obj;
-    xc_cpu_to_node_t map[MAX_CPU_ID + 1];
+    PyObject *pcpu_tuples_obj;
+    xc_cpu_to_node_t map_thread[MAX_CPU_ID + 1];
+    xc_cpu_to_node_t map_core[MAX_CPU_ID + 1];
+    xc_cpu_to_node_t map_socket[MAX_CPU_ID + 1];
+    xc_cpu_to_node_t map_node[MAX_CPU_ID + 1];
     const char *virtcap_names[] = { "hvm", "hvm_directio" };
 
-    set_xen_guest_handle(info.cpu_to_node, map);
+    set_xen_guest_handle(info.cpu_to_core, map_core);
+    set_xen_guest_handle(info.cpu_to_socket, map_socket);
+    set_xen_guest_handle(info.cpu_to_node, map_node);
     info.max_cpu_id = MAX_CPU_ID;
 
     if ( xc_physinfo(self->xc_handle, &info) != 0 )
@@ -1099,6 +1105,43 @@
     if ( max_cpu_id > MAX_CPU_ID )
         max_cpu_id = MAX_CPU_ID;
 
+    /* Assumes cpu siblings are listed consecutively */
+    for ( i = 0; i <= max_cpu_id; i++ )
+    {
+        uint32_t cpu_thread_id;
+        if (map_core[i] == INVALID_TOPOLOGY_ID)
+            continue;
+
+        cpu_thread_id = 0;
+        map_thread[i] = cpu_thread_id++;
+
+        for ( j = i+1; (map_core[i] == map_core[j]) && (j <= max_cpu_id); j++ )
+            map_thread[j] = cpu_thread_id++;
+
+        i = j;
+    }
+
+    /* Construct cpu-to-* lists */
+    pcpu_tuples_obj = PyList_New(0);
+
+    for ( i = 0; i <= max_cpu_id; i++ )
+    {
+        PyObject *pcpu_tuple;
+        PyObject *pyint;
+        pcpu_tuple = PyList_New(0);
+        pyint = PyInt_FromLong(map_node[i]);
+        PyList_Append(pcpu_tuple, pyint);
+        pyint = PyInt_FromLong(map_socket[i]);
+        PyList_Append(pcpu_tuple, pyint);
+        pyint = PyInt_FromLong(map_core[i]);
+        PyList_Append(pcpu_tuple, pyint);
+        pyint = PyInt_FromLong(map_thread[i]);
+        PyList_Append(pcpu_tuple, pyint);
+        Py_DECREF(pyint);
+        PyList_Append(pcpu_tuples_obj, pcpu_tuple);
+        Py_DECREF(pcpu_tuple);
+    }
+
     /* Construct node-to-cpu lists. */
     node_to_cpu_obj = PyList_New(0);
 
@@ -1107,7 +1150,7 @@
     {
         PyObject *cpus = PyList_New(0);
         for ( j = 0; j <= max_cpu_id; j++ )
-            if ( i == map[j]) {
+            if ( i == map_node[j]) {
                 PyObject *pyint = PyInt_FromLong(j);
                 PyList_Append(cpus, pyint);
                 Py_DECREF(pyint);
@@ -1128,6 +1171,8 @@
         Py_DECREF(pyint);
     }
 
+    PyDict_SetItemString(ret_obj, "pcpu_tuples", pcpu_tuples_obj);
+    Py_DECREF(pcpu_tuples_obj);
     PyDict_SetItemString(ret_obj, "node_to_cpu", node_to_cpu_obj);
     Py_DECREF(node_to_cpu_obj);
     PyDict_SetItemString(ret_obj, "node_to_memory", node_to_memory_obj);
diff -r b6b2e97f8db9 tools/python/xen/xend/XendNode.py
--- a/tools/python/xen/xend/XendNode.py	Fri Nov 13 22:13:59 2009 +0000
+++ b/tools/python/xen/xend/XendNode.py	Tue Nov 17 01:48:24 2009 -0500
@@ -763,6 +763,10 @@
         else:
             return 'unknown'
 
+    def pcpu_tuples(self):
+        phys_info = self.xc.physinfo()
+        return phys_info["pcpu_tuples"]
+
     def get_cpu_configuration(self):
         phys_info = self.physinfo_dict()
 
@@ -872,6 +876,7 @@
         except:
             str='none\n'
         return str[:-1];
+
     def format_node_to_memory(self, pinfo):
         str=''
         whitespace=''
@@ -886,7 +891,6 @@
             str='none\n'
         return str[:-1];
 
-
     def physinfo(self):
         info = self.xc.physinfo()
 
diff -r b6b2e97f8db9 tools/python/xen/xend/server/XMLRPCServer.py
--- a/tools/python/xen/xend/server/XMLRPCServer.py	Fri Nov 13 22:13:59 2009 +0000
+++ b/tools/python/xen/xend/server/XMLRPCServer.py	Tue Nov 17 01:48:24 2009 -0500
@@ -199,7 +199,7 @@
 
         # Functions in XendNode and XendDmesg
         for type, lst, n in [(XendNode,
-                              ['info', 'pciinfo', 'send_debug_keys',
+                              ['info','pcpu_tuples','pciinfo','send_debug_keys',
                                'tmem_list', 'tmem_freeze', 'tmem_thaw',
                                'tmem_flush', 'tmem_destroy', 'tmem_set_weight',
                                'tmem_set_cap', 'tmem_set_compress',
diff -r b6b2e97f8db9 tools/python/xen/xm/main.py
--- a/tools/python/xen/xm/main.py	Fri Nov 13 22:13:59 2009 +0000
+++ b/tools/python/xen/xm/main.py	Tue Nov 17 01:48:24 2009 -0500
@@ -156,10 +156,11 @@
                      'Send a trigger to a domain.'),
     'vcpu-list'   : ('[Domain, ...]',
                      'List the VCPUs for all/some domains.'),
-    'vcpu-pin'    : ('<Domain> <VCPU|all> <CPUs|all>',
+    'vcpu-pin'    : ('<Domain> <VCPU|all> <CPUs|all|pcpu-tuple>\n'
+                     'pcpu-tuple : node.socket.core.thread',
                      'Set which CPUs a VCPU can use.'),
     'vcpu-set'    : ('<Domain> <vCPUs>',
-                     'Set the number of active VCPUs for allowed for the'
+                     'Set the number of active VCPUs allowed for the'
                      ' domain.'),
     #usb
     'usb-add'     : ('<domain> <[host:bus.addr] [host:vendor_id:product_id]>','Add the usb device to FV VM.'),
@@ -1433,12 +1434,29 @@
 
 
 #############################################################
-
 def xm_vcpu_pin(args):
     arg_check(args, "vcpu-pin", 3)
 
+    def cpumap_from_tuple(cpulist):
+        pcpu_tuples = server.xend.node.pcpu_tuples()
+        cpus = []
+        (n,s,c,t) = cpulist.split('.')
+        for i in range(0, len(pcpu_tuples)):
+            if (n == '*') or (int(n) == pcpu_tuples[i][0]):
+                if (s == '*') or (int(s) == pcpu_tuples[i][1]):
+                    if (c == '*') or (int(c) == pcpu_tuples[i][2]):
+                        if (t == '*') or (int(t) == pcpu_tuples[i][3]):
+                            cpus.append(int(i))
+        cpus.sort()
+        return ",".join(map(str, cpus))
+
     def cpu_make_map(cpulist):
         cpus = []
+        # Dotted tuples (node.socket.core.thread)
+        if cpulist.find('.') != -1:
+            cpumap = cpumap_from_tuple(cpulist)
+            return cpumap
+
         for c in cpulist.split(','):
             if c.find('-') != -1:
                 (x,y) = c.split('-')
@@ -1819,6 +1837,7 @@
         for (k, v) in sorted:
            print "%-23s:" % k, v 
     else:
+        print "xm_info : comes here !!"
         info = server.xend.node.info()
         for x in info[1:]:
             if len(x) < 2: 
diff -r b6b2e97f8db9 xen/arch/x86/sysctl.c
--- a/xen/arch/x86/sysctl.c	Fri Nov 13 22:13:59 2009 +0000
+++ b/xen/arch/x86/sysctl.c	Tue Nov 17 01:48:24 2009 -0500
@@ -46,6 +46,8 @@
     case XEN_SYSCTL_physinfo:
     {
         uint32_t i, max_array_ent;
+        XEN_GUEST_HANDLE_64(uint32) cpu_to_core_arr;
+        XEN_GUEST_HANDLE_64(uint32) cpu_to_socket_arr;
         XEN_GUEST_HANDLE_64(uint32) cpu_to_node_arr;
 
         xen_sysctl_physinfo_t *pi = &sysctl->u.physinfo;
@@ -55,9 +57,14 @@
             break;
 
         max_array_ent = pi->max_cpu_id;
+        cpu_to_core_arr = pi->cpu_to_core;
+        cpu_to_socket_arr = pi->cpu_to_socket;
         cpu_to_node_arr = pi->cpu_to_node;
 
         memset(pi, 0, sizeof(*pi));
+
+        pi->cpu_to_core = cpu_to_core_arr;
+        pi->cpu_to_socket = cpu_to_socket_arr;
         pi->cpu_to_node = cpu_to_node_arr;
         pi->threads_per_core =
             cpus_weight(per_cpu(cpu_sibling_map, 0));
@@ -84,7 +91,8 @@
         {
             for ( i = 0; i <= max_array_ent; i++ )
             {
-                uint32_t node = cpu_online(i) ? cpu_to_node(i) : ~0u;
+                uint32_t node = 
+                    cpu_online(i) ? cpu_to_node(i) : INVALID_TOPOLOGY_ID;
                 if ( copy_to_guest_offset(cpu_to_node_arr, i, &node, 1) )
                 {
                     ret = -EFAULT;
@@ -93,6 +101,34 @@
             }
         }
 
+        if ( !guest_handle_is_null(cpu_to_core_arr) )
+        {
+            for ( i = 0; i <= max_array_ent; i++ )
+            {
+                uint32_t core = 
+                    cpu_online(i) ? cpu_to_core(i) : INVALID_TOPOLOGY_ID;
+                if ( copy_to_guest_offset(cpu_to_core_arr, i, &core, 1) )
+                {
+                    ret = -EFAULT;
+                    break;
+                }
+            }
+        }
+        
+        if ( !guest_handle_is_null(cpu_to_socket_arr) )
+        {
+            for ( i = 0; i <= max_array_ent; i++ )
+            {
+                uint32_t socket = 
+                    cpu_online(i) ? cpu_to_socket(i) : INVALID_TOPOLOGY_ID;
+                if ( copy_to_guest_offset(cpu_to_socket_arr, i, &socket, 1) )
+                {
+                    ret = -EFAULT;
+                    break;
+                }
+            }
+        }
+        
         if ( copy_to_guest(u_sysctl, sysctl, 1) )
             ret = -EFAULT;
     }
diff -r b6b2e97f8db9 xen/include/public/sysctl.h
--- a/xen/include/public/sysctl.h	Fri Nov 13 22:13:59 2009 +0000
+++ b/xen/include/public/sysctl.h	Tue Nov 17 01:48:24 2009 -0500
@@ -115,8 +115,9 @@
      * If the actual @max_cpu_id is smaller than the array then the trailing
      * elements of the array will not be written by the sysctl.
      */
+    XEN_GUEST_HANDLE_64(uint32) cpu_to_core;
+    XEN_GUEST_HANDLE_64(uint32) cpu_to_socket;
     XEN_GUEST_HANDLE_64(uint32) cpu_to_node;
-
     /* XEN_SYSCTL_PHYSCAP_??? */
     uint32_t capabilities;
 };

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH]pcpu tuples [was Re: [Xen-devel] Xen 3.4.1 NUMA support]

[Keir Fraser]

I think this is good. However, the socket and node ids can be fairly
arbitrary small numbers -- we need a way for the admin to find out the
topology and 'addresses' of physical cpus via xm. Perhaps a new 'xm
cpu-list' command to basically dump the pcpu_tuple information in ascending
order of node, then socket, then core, then thread, with one row per cpu:
 node socket core thread xen-cpu-id

More info could be added beyond these five pieces of information, as we
later see fit.

An alternative would be to rename the socket/node identifiers in
pyxc_physinfo, or even in Xen itself, to achieve contiguity. However I think
a cpu-list command would still be useful, and it's easy to implement.

 -- Keir

On 17/11/2009 06:56, "Dulloor" <dulloor@gmail.com> wrote:

> Attached is a patch to construct pcpu tuples of the form
> (node.socket.core.thread), and (currently)used by xm vcpu-pin utility.
> 
> -dulloor
> 
> On Fri, Nov 13, 2009 at 11:02 AM, Keir Fraser <keir.fraser@eu.citrix.com>
> wrote:
>> On 13/11/2009 15:40, "Ian Pratt" <Ian.Pratt@eu.citrix.com> wrote:
>> 
>>>> Even better would be to have pCPUs addressable and listable explicitly as
>>>> dotted tuples. That can be implemented entirely within the toolstack, and
>>>> could even allow wildcarding of tuple components to efficiently express
>>>> cpumasks.
>>> 
>>> Yes, I'd certainly like to see the toolstack support dotted tuple notation.
>>> 
>>> However, I just don't trust the toolstack to get this right unless xen has
>>> already set it up nicely for it with a sensible enumeration and defined
>>> sockets-per-node, cores-per-socket and threads-per-core parameters. Xen
>>> should
>>> provide a clean interface to the toolstack in this respect.
>> 
>> Xen provides a topology-interrogation hypercall which should suffice for
>> tools to build up a {node,socket,core,thread}<->cpuid mapping table.
>> 
>>  -- Keir
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>> 

RE: [PATCH]pcpu tuples [was Re: [Xen-devel] Xen 3.4.1 NUMA support]

[Jiang, Yunhong]

Hi, dulloor/keir, for the changes to XEN_SYSCTL_physinfo, I'm not sure part of my work will be helpful.

I sent out a patch to present pcpu information in dom0's /sys/devices/system/xen_pcpu/pcpuX directory. Currently I simply present the apic_id/acpi_id in this directory for cpu hotplug.
But how about using it to present the whole topology information, for example, we can add initial_apicid/core_id etc to the xen_pcpu/pcpuX directory.

Furthermore, if we can create a directory like /sys/devices/system/xen_pcpu/pcpuX/topology, make the arrangement below this directory same as native linux's cpu directory in sysfs, I think it will benifit more. For example, we can simply change current linux tools to show the topo information (just /sys/device/system/cpu/ to  /sys/devices/system/xen_pcpu/).

Of course, I understand maybe most management tools for virtualization will be different with native tools, but this similar arrangement will be helpful still.

Any idea?

--jyh

xen-devel-bounces@lists.xensource.com wrote:
> [Xen-devel] Xen 3.4.1 NUMA support]
> 
> I think this is good. However, the socket and node ids can be fairly
> arbitrary small numbers -- we need a way for the admin to find out the
> topology and 'addresses' of physical cpus via xm. Perhaps a new 'xm
> cpu-list' command to basically dump the pcpu_tuple information
> in ascending
> order of node, then socket, then core, then thread, with one
> row per cpu:
> node socket core thread xen-cpu-id
> 
> More info could be added beyond these five pieces of information, as
> we later see fit. 
> 
> An alternative would be to rename the socket/node identifiers in
> pyxc_physinfo, or even in Xen itself, to achieve contiguity.
> However I think
> a cpu-list command would still be useful, and it's easy to implement.
> 
> -- Keir
> 
> On 17/11/2009 06:56, "Dulloor" <dulloor@gmail.com> wrote:
> 
>> Attached is a patch to construct pcpu tuples of the form
>> (node.socket.core.thread), and (currently)used by xm vcpu-pin
>> utility. 
>> 
>> -dulloor
>> 
>> On Fri, Nov 13, 2009 at 11:02 AM, Keir Fraser
>> <keir.fraser@eu.citrix.com> wrote:
>>> On 13/11/2009 15:40, "Ian Pratt" <Ian.Pratt@eu.citrix.com> wrote:
>>> 
>>>>> Even better would be to have pCPUs addressable and listable
>>>>> explicitly as dotted tuples. That can be implemented entirely
>>>>> within the toolstack, and could even allow wildcarding of tuple
>>>>> components to efficiently express cpumasks.
>>>> 
>>>> Yes, I'd certainly like to see the toolstack support dotted tuple
>>>> notation. 
>>>> 
>>>> However, I just don't trust the toolstack to get this right unless
>>>> xen has already set it up nicely for it with a sensible
>>>> enumeration and defined sockets-per-node, cores-per-socket and
>>>> threads-per-core parameters. Xen should provide a clean interface
>>>> to the toolstack in this respect. 
>>> 
>>> Xen provides a topology-interrogation hypercall which should
>>> suffice for tools to build up a {node,socket,core,thread}<->cpuid
>>> mapping table. 
>>> 
>>>  -- Keir
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH]pcpu tuples [was Re: [Xen-devel] Xen 3.4.1 NUMA support]

[Andre Przywara]

Dulloor wrote:
> Attached is a patch to construct pcpu tuples of the form
> (node.socket.core.thread), and (currently)used by xm vcpu-pin utility.
Without having looked further at the patch: There will be problems with 
that notation. The assumption that one node consist of at least one 
socket is no longer true with AMD's upcoming Magny-Cours processors, 
which features _two_ nodes in one socket.
The socket information as it is of interest for licensing purposes and 
for the voltage domains. I suppose that power aware scheduling is out of 
scope for the current scheduler, so we could ignore the socket 
information here at all.
Shared cache would be an interesting information to consider for 
scheduling purposes, but again here the socket information is 
misleading, as each node of the Magny-Cours processor has it's own L3 
cache, there is no cache shared across the two nodes in one package.
Xen already detects the NUMA topology on the new system correctly:
nr_cpus                : 48
nr_nodes               : 8
cores_per_socket       : 12
threads_per_core       : 1
I don't know details about the usual IA64 topology, though.

I see currently these possible topologies for x86-64 systems:
Core2-based: 1 (fake) node, n sockets
AMD64/Nehalem: n nodes, 1 socket/node
AMD G34: n nodes, 2 or 1 nodes/socket(!)
That looks like that it will not be easy to combine all of those. One 
possibility would be to join nodes and sockets into one entity (use 
sockets on older systems (L2 cache domains) and nodes on AMD/newer Intel 
systems (memory controller domains)). But I don't have a handy name for 
that beast (left alone nockets ;-)


Although it can be quite useful to have such a notation, I am not sure 
whether it will really help. Eventually you want to go away from manual 
assignment (and be it at domain's runtime via "xm vcpu-pin").

Looking forward to any comments.

Regards,
Andre.

> 
> -dulloor
> 
> On Fri, Nov 13, 2009 at 11:02 AM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
>> On 13/11/2009 15:40, "Ian Pratt" <Ian.Pratt@eu.citrix.com> wrote:
>>
>>>> Even better would be to have pCPUs addressable and listable explicitly as
>>>> dotted tuples. That can be implemented entirely within the toolstack, and
>>>> could even allow wildcarding of tuple components to efficiently express
>>>> cpumasks.
>>> Yes, I'd certainly like to see the toolstack support dotted tuple notation.
>>>
>>> However, I just don't trust the toolstack to get this right unless xen has
>>> already set it up nicely for it with a sensible enumeration and defined
>>> sockets-per-node, cores-per-socket and threads-per-core parameters. Xen should
>>> provide a clean interface to the toolstack in this respect.
>> Xen provides a topology-interrogation hypercall which should suffice for
>> tools to build up a {node,socket,core,thread}<->cpuid mapping table.
>>
>>  -- Keir
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>


-- 
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712

Re: [PATCH]pcpu tuples [was Re: [Xen-devel] Xen 3.4.1 NUMA support]

[Jan Beulich]

>>> Andre Przywara <andre.przywara@amd.com> 19.11.09 10:05 >>>
>Without having looked further at the patch: There will be problems with 
>that notation. The assumption that one node consist of at least one 
>socket is no longer true with AMD's upcoming Magny-Cours processors, 
>which features _two_ nodes in one socket.

Hmm, the term "node" doesn't seem right here: How would you call the
aggregation of several sockets to a unit, several of which could form a
bigger system (which is what so far is being called "node" afaict)?

Jan

RE: [PATCH]pcpu tuples [was Re: [Xen-devel] Xen 3.4.1 NUMA support]

[Dan Magenheimer]

> From: Jan Beulich [mailto:JBeulich@novell.com]
> Sent: Thursday, November 19, 2009 2:33 AM
> To: Andre Przywara
> Cc: George Dunlap; Ian Pratt; Keir Fraser; Dulloor; Papagiannis
> Anastasios; xen-devel@lists.xensource.com; Dan Magenheimer
> Subject: Re: [Xen-devel][PATCH]pcpu tuples [was Re: [Xen-devel] Xen
> 3.4.1 NUMA support]
> 
> 
> >>> Andre Przywara <andre.przywara@amd.com> 19.11.09 10:05 >>>
> >Without having looked further at the patch: There will be 
> problems with 
> >that notation. The assumption that one node consist of at least one 
> >socket is no longer true with AMD's upcoming Magny-Cours processors, 
> >which features _two_ nodes in one socket.
> 
> Hmm, the term "node" doesn't seem right here: How would you call the
> aggregation of several sockets to a unit, several of which 
> could form a
> bigger system (which is what so far is being called "node" afaict)?

Actually, I think it is the term "socket" that is now irrelevant.
While it is interesting from the point-of-view of a computer
vendor and for software licensing, it is irrelevant for a
scheduler.  What is important I think is:

"buddies"
- cpus within this unit MUST share a memory controller
- cpus within this unit MUST share at least one level of cache

"grouping"
- cpus within the same "grouping" MUST share a memory controller
- cpus in different "groupings" MUST NOT share a cache

"node"
- cpus in different nodes MUST NOT share a memory controller

Is ACPI able to describe these differences today?  If not,
has any of this been discussed on lkml or in acpi mailing lists?
How is Linux (and KVM and VMware and Hyper-V) dealing with
this new level of topology?