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] [PATCH] initialize some more cpuinfo fields

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] initialize some more cpuinfo fields
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Mon, 08 May 2006 16:18:19 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 08 May 2006 07:17:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <bcc309c7d46b56fc31e28c806eacd0c1@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <445F5F50.76E4.0078.0@xxxxxxxxxx> <bcc309c7d46b56fc31e28c806eacd0c1@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 08.05.06 15:46 >>>
>On 8 May 2006, at 14:10, Jan Beulich wrote:
>> Namely preventing systems to look like single-socket ones with many 
>> cores (because all CPUs show physical ID being
>> zero).
>Is it a problem to look like a many-core processor? Given that VCPUS 
>can get moved around between physical CPUs to load-balance, it doesn't 
>make much sense to take the physical IDs of CPUs that VCPUs happen to 
>run on when they boot.

Yes, we have an irqbalance userland package that is, as I'm told, supposed to 
run only on multi-socket systems.

>If the many-core appearance is a problem then we could synthesise 
>different physical IDs for VCPUs (probably by forcing physical ID to 
>VCPU number).

This is what the patch does (it simply overrides whatever identify_cpu() 

>The only exception to this 'lie' could perhaps be domain0 in some 
>situations, if we guarantee to run a dom0 VCPU on every physical CPU 
>and never change the pinning. Then calling identify_cpu() for each VCPU 
>makes sense, as does parsing SRAT data or otherwise obtaining NUMA info 
>via a Xen hypercall.

Yes, if such a guarantee was made, then dom0 should behave like native (and 
should specifically also have/call
set_cpu_sibling_map()), provided there are not currently any implications on 
cpu_sibling_map or cpu_core_map in the Xen
specific code.


Xen-devel mailing list