| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] initialize some more cpuinfo fields
>>> 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
|
|
|
| |
|
Home