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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

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

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

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