Xen devel - May 2006 - [PATCH] initialize some more cpuinfo fields

Namely preventing systems to look like single-socket ones with many cores
(because all CPUs show physical ID being
zero).

Signed-off-by: Jan Beulich <jbeulich@novell.com>


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

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.

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

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.

  -- Keir


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

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 8 May 2006, at 15:18, Jan Beulich wrote:
>> 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).
Why add the copy from boot_cpu_data, or the call to identify_cpu(), at 
all? We already initialise the cpu_data in smp_prepare_cpus(), and we 
set up the cpu_to_apicid array at the same time. Why not lie about 
cpu_data->apicid, and set phys_proc_id[cpu], at the same time in the 
same function?

That would be a one- or two-liner, plus maybe your modification of 
booted_cores if that''s still needed.

  -- Keir


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

On 8 May 2006, at 15:52, Jan Beulich wrote:
>> set up the cpu_to_apicid array at the same time. Why not lie about
>> cpu_data->apicid, and set phys_proc_id[cpu], at the same time in the
>> same function?
>
> Certainly an option, but keeping it in cpu_bringup() will allow easier 
> change once the dom0 special casing you talked
> about would be wanted/needed (because then you clearly *want* to call 
> identify_cpu() and not lie about anything).
How early during boot do these things need to be set up? We may also 
want to support static NUMA topologies for domU guests as well, under 
some circumstances. Is it okay to set that up in cpu_bringup() even 
though the CPUs may be brought online only after the OS is fully 
booted? Or is it better to set up the mapping arrays and so on early in 
smp_prepare_cpus()? The latter is possible since vcpu0 could 
interrogate Xen via a new vcpu_op sub-hypercall.

I think I''d rather keep the code where it is for now, and simply add 
identify_cpu() to cpu_bringup() later when we support that for domain0. 
That will simply act as a dynamic reconfiguration of the mappings and 
relationships that get simply statically initialised in 
smp_prepare_cpus().

  -- Keir


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

>I think I''d rather keep the code where it is for now, and simply
add
>identify_cpu() to cpu_bringup() later when we support that for domain0. 
>That will simply act as a dynamic reconfiguration of the mappings and 
>relationships that get simply statically initialised in 
>smp_prepare_cpus().
I think I''m fine with that.

Jan

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