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

[Wei Huang <wei.huang2@amd.com>]

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.

-Wei

On 01/11/2011 05:12 AM, George Dunlap wrote:
> On Tue, Jan 11, 2011 at 10:58 AM, George Dunlap<dunlapg@umich.edu>  wrote:
>> On Fri, Jan 7, 2011 at 3:52 PM, Huang2, Wei<Wei.Huang2@amd.com>  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
>