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] RE: [RFC][PATCH] AMD CPU core topology detection

Hi George,

The analogy holds for most parts. Following with Jan's recommendation, I will add a new compute_unit_id to each logic processor, with the hope of minimizing the impacts to Xen. No, it won't use is_amd() style of statements.


On 01/11/2011 05:12 AM, George Dunlap wrote:
On Tue, Jan 11, 2011 at 10:58 AM, George Dunlap<dunlapg@xxxxxxxxx>  wrote:
On Fri, Jan 7, 2011 at 3:52 PM, Huang2, Wei<Wei.Huang2@xxxxxxx>  wrote:
[From my understanding, cpu_core_id and phys_proc_id are collected during boot (mostly 
in smpboot.c and under cpu/ directory) for sibling map. The sibling info is used for 
scheduler later on. Old AMD CPUs don't have HyperThreading, so the cpu_sibling_map isn't 
so useful. New CPUs will have core/compute unit/node. Using Intel's HT as an analogy, we 
have the following relationship: core=>hyper-thread, compute unit=>core, 
node=>processor). From that perspective, the change is reasonable. But I might have 
missed other parts.
Wei, can you point me to some documentation about exactly what the
"compute unit" is?
[Sorry, accidentally sent too early]

If there's a strong logical correspondence between Intel's "thread ->
core ->  socket" and AMD's "core ->  compute unit ->  node", then I think
reusing the maps makes sense; but if there's a fairly significant
difference, then I think coming up with a different naming convention
would be best.  I don't like the idea of having code that says
"if(is_intel()) { /* Do things one way */} ; else if (is_amd()) { /*
Do things a different way */}".  Not only is it ugly, it's a set-up
for bugs.


Xen-devel mailing list