From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Huang Subject: Re: RE: [RFC][PATCH] AMD CPU core topology detection Date: Tue, 11 Jan 2011 11:05:29 -0600 Message-ID: <4D2C8DD9.2060507@amd.com> References: <4D25F227.4060808@amd.com> <4D26E350020000780002AF0B@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: George Dunlap Cc: "xen-devel@lists.xensource.com" , "keir@xen.org" , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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 wrote: >> On Fri, Jan 7, 2011 at 3:52 PM, Huang2, Wei 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 >