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

[Wei Huang <wei.huang2@xxxxxxx>]

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