This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Jan Beulich <JBeulich@xxxxxxxxxx>, Andre Przywara <andre.przywara@xxxxxxx>
Subject: RE: [Xen-devel][PATCH]pcpu tuples [was Re: [Xen-devel] Xen 3.4.1 NUMA support]
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Thu, 19 Nov 2009 07:33:15 -0800 (PST)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Dulloor <dulloor@xxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Papagiannis Anastasios <apapag@xxxxxxxxxxxx>
Delivery-date: Thu, 19 Nov 2009 07:34:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B051EF40200007800020C8A@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Sent: Thursday, November 19, 2009 2:33 AM
> To: Andre Przywara
> Cc: George Dunlap; Ian Pratt; Keir Fraser; Dulloor; Papagiannis
> Anastasios; xen-devel@xxxxxxxxxxxxxxxxxxx; Dan Magenheimer
> Subject: Re: [Xen-devel][PATCH]pcpu tuples [was Re: [Xen-devel] Xen
> 3.4.1 NUMA support]
> >>> Andre Przywara <andre.przywara@xxxxxxx> 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:

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

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

- 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?

Xen-devel mailing list