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

To: "Huang2, Wei" <Wei.Huang2@xxxxxxx>
Subject: Re: [Xen-devel] RE: [RFC][PATCH] AMD CPU core topology detection
From: George Dunlap <dunlapg@xxxxxxxxx>
Date: Tue, 11 Jan 2011 11:12:59 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "keir@xxxxxxx" <keir@xxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Tue, 11 Jan 2011 03:57:49 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=mU54l8w+OaW/cxwT0kBE8FQl5YiOKFEbmvgf3iOouKM=; b=FU5fhChHEiCoCwse/aYu7Y1ep9hygVaeyqHS8SogFVpb0YlB3D1scHfybV2OlM4JcS IjLqxPWD3dolBpiqAfFB0CXMUr4N11Krs0DAuMZCES1A3cjX2/2t6BA38pur/Yqd26cO tfq1wXjJ/WJADQGt3gPoLO/sCxvXFL9pkAHs8=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=BgK1Y2zqTYq0byFjt6n7SJLRpTe8AwUl5dlyCFtOiEHTA9QpCZXyvQRuvEHAv1vz56 Agvubm3My/JzNgZukXkWCeO3KXaLC07qvJVsBKx7zKRL/gIXdYjtcq9227HqKBUGrLPS KH6S7Qk2icjcitGnoJ9JFNQGIW7ffijNnbfyU=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTikVtOrc8N4O1hmxHezdfA1A6tLEAPbyA534N93W@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D25F227.4060808@xxxxxxx> <4D26E350020000780002AF0B@xxxxxxxxxxxxxxxxxx> <EE335F95F28A664DB4A21289D2AA053BB4CCB2A7@xxxxxxxxxxxxxxxxxxx> <AANLkTikVtOrc8N4O1hmxHezdfA1A6tLEAPbyA534N93W@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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