From mboxrd@z Thu Jan  1 00:00:00 1970
From: George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [PATCH 0/2] Credit2: fix per-socket runqueue setup
Date: Wed, 3 Sep 2014 11:00:48 +0100
Message-ID: <5406E6D0.5060505@eu.citrix.com>
References: <20140822165628.32764.15082.stgit@Solace.lan>	
	<53FB1088020000780002D105@mail.emea.novell.com>	
	<54047BBB.3050507@eu.citrix.com>
	<1409676377.2673.12.camel@Solace.lan>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1XP7NG-0006wB-9N
	for xen-devel@lists.xenproject.org; Wed, 03 Sep 2014 10:01:10 +0000
In-Reply-To: <1409676377.2673.12.camel@Solace.lan>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, keir@xen.org, Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
List-Id: xen-devel@lists.xenproject.org

On 09/02/2014 05:46 PM, Dario Faggioli wrote:
> Me neither. BTW, on baremetal, here's what I see:
> root@tg03:~# numactl --hardware
> available: 2 nodes (0-1)
> node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22
> node 0 size: 18432 MB
> node 0 free: 17927 MB
> node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23
> node 1 size: 18419 MB
> node 1 free: 17926 MB
> node distances:
> node   0   1
>    0:  10  20
>    1:  20  10
>
> Also:
> root@tg03:~# for i in `seq 0 23`;do echo "CPU$i is on socket `cat /sys/bus/cpu/devices/cpu$i/topology/physical_package_id`";done
> CPU0 is on socket 1
> CPU1 is on socket 0
> CPU2 is on socket 1
> CPU3 is on socket 0
> CPU4 is on socket 1
> CPU5 is on socket 0
> CPU6 is on socket 1
> CPU7 is on socket 0
> CPU8 is on socket 1
> CPU9 is on socket 0
> CPU10 is on socket 1
> CPU11 is on socket 0
> CPU12 is on socket 1
> CPU13 is on socket 0
> CPU14 is on socket 1
> CPU15 is on socket 0
> CPU16 is on socket 1
> CPU17 is on socket 0
> CPU18 is on socket 1
> CPU19 is on socket 0
> CPU20 is on socket 1
> CPU21 is on socket 0
> CPU22 is on socket 1
> CPU23 is on socket 0
>
> I've noticed this before, but, TBH, I never dug the cause of the
> discrepancy between us and Linux.

I remember at some point Xen purposely re-enumerating the cpu numbers so 
that they would have a more sensible arrangement -- i.e., you could 
expect logical cpus on the same thread / core / socket to be grouped 
together consecutively.

As you can see here though, cpu 0 is still on socket 1 (which is 
probably why Xen keeps cpu 0 on socket 1 in its re-enumertation).

  -George