From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Theurer <habanero@us.ibm.com>
Subject: Re: [PATCH] changeset 8831 gets sockets, cores,
	and siblings wrong
Date: Thu, 16 Feb 2006 12:18:36 -0600
Message-ID: <43F4C1FC.9000405@us.ibm.com>
References: <43F39B4B.6080806@us.ibm.com>
	<d78f897640ab3448e8e8a283497e9ff1@cl.cam.ac.uk>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="------------000702010209010500090204"
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <d78f897640ab3448e8e8a283497e9ff1@cl.cam.ac.uk>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org

This is a multi-part message in MIME format.
--------------000702010209010500090204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Keir Fraser wrote:
>
> On 15 Feb 2006, at 21:21, Andrew Theurer wrote:
>
>> FWIW, I noticed that changeset 8831 gets the sockets/cores/siblings 
>> incorrect on my system.  On 8830 I get 4 sockets per node, 2 cores 
>> per socket, and 2 threads per core.  On 8831 I get 1 socket per node, 
>> 2 cores per socket, and 8 threads per core.  Xen boot messages still 
>> appear to show four distinct physical cpus (sockets).  Just wondering 
>> if anyone has noticed this behavior.
>
> This all stems from an incorrect value for smp_num_siblings. This 
> could come from one of two places:
>  1. Do you get a message 'WARNING: 8 siblings found for CPUx, should 
> be 2' during boot? If so, smpboot.c is screwing up the 
> smp_num_siblings calculation.
>  2. Otherwise, detect_ht() in arch/x86/cpu/common.c must be the 
> culprit, and you'll need to add some tracing to it to find out where 
> the value '8' is coming from.
It looks like with changeset 8831 cpu_core_ids are no longer unique 
across phys cpus.  So, when we search for siblings to populate 
cpu_sibling_map, just checking for same core IDs are not good enough.  
Both core ID and phys cpu ID have to match.  Patch attached fixes this.

-Andrew

<signed-off-by: habanero@us.ibm.com>

--------------000702010209010500090204
Content-Type: text/x-patch;
 name="fix_sibling_calc-8849.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="fix_sibling_calc-8849.patch"

diff -Naurp xen-unstable.hg-8849/xen/arch/x86/smpboot.c xen-unstable.hg-8849-sibling_fix/xen/arch/x86/smpboot.c
--- xen-unstable.hg-8849/xen/arch/x86/smpboot.c	2006-02-16 12:15:53.000000000 -0600
+++ xen-unstable.hg-8849-sibling_fix/xen/arch/x86/smpboot.c	2006-02-16 12:11:33.000000000 -0600
@@ -1093,7 +1093,8 @@ static void __init smp_boot_cpus(unsigne
 			for (i = 0; i < NR_CPUS; i++) {
 				if (!cpu_isset(i, cpu_callout_map))
 					continue;
-				if (cpu_core_id[cpu] == cpu_core_id[i]) {
+				if (cpu_core_id[cpu] == cpu_core_id[i] && 
+                                    phys_proc_id[cpu] == phys_proc_id[i]) {
 					siblings++;
 					cpu_set(i, cpu_sibling_map[cpu]);
 				}

--------------000702010209010500090204
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------000702010209010500090204--