Re: [Xen-devel] [PATCH] initialize some more cpuinfo fields

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> 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() 
provided).

>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.

Jan

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