Re: [Xen-devel] RE: [RFC][PATCH] AMD CPU core topology detection

[George Dunlap <dunlapg@xxxxxxxxx>]

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.

 -George

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