|
xen-devel
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.
-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
|
|
|
Home