Re: [Xen-devel] [PATCH v6 01/14] x86: add socket_to_cpumask

[Chao Peng <chao.p.peng@xxxxxxxxxxxxxxx>]

On Tue, May 05, 2015 at 10:11:15AM +0100, Jan Beulich wrote:
> >>> On 05.05.15 at 09:44, <chao.p.peng@xxxxxxxxxxxxxxx> wrote:
> > On Fri, Apr 24, 2015 at 03:46:11PM +0100, Jan Beulich wrote:
> >> >>> On 23.04.15 at 11:55, <chao.p.peng@xxxxxxxxxxxxxxx> wrote:
> >> > @@ -717,6 +722,14 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
> >> >  
> >> >      stack_base[0] = stack_start;
> >> >  
> >> > +    nr_sockets = DIV_ROUND_UP(nr_cpu_ids, boot_cpu_data.x86_max_cores *
> >> > +                                          
> >> > boot_cpu_data.x86_num_siblings);
> >> 
> >> I think this is going to be problematic when there are more CPUs
> >> in the system than Xen can (or is told to) handle.
> > 
> > After dived into the code I think there is no way we can do it
> > correctly, especially when we want to get the nr_sockets which counts
> > in the unplugged socket(s) as well.
> 
> Without you explaining why it's really hard to judge whether that's
> indeed the case. After all we have all necessary information in hand
> when booting all CPUs, so I can't see why we shouldn't be able to
> use that information also when booting only a subset.

My concern is the original APIC IDs do not need to be consecutive. Then
in such case even we do

DIV_ROUND_UP(cpu_num_from_madt, boot_cpu_data.x86_max_cores *
                                boot_cpu_data.x86_num_siblings);

would not be correct.

E.g. If we have a machine like this (Each package has two cores and each
core has two threads but only 3 processors enumerated in MADT):

APIC_ID  Package_ID Core_ID SMT_ID
 1(001)  0          0       1
 2(010)  0          1       0
 4(100)  1          0       0

Then nr_sockets = ROUND_UP( 3 / (2 * 2) ) = 1 but we do have two sockets.

Chao
> 
> > One possible way is to culculate the package mask from cpuid topology
> > first and then use it to culculate the possible sockets. It should work
> > but is also wasteful. For me, it's unacceptable.
> 
> Again, without you being more specific I can't really comment.
> 
> > Another way would be make a build time macro NR_SOCKETS, which is not so
> > flexible but makes all things easy.
> > 
> > Also, if you think it's needed, I can add a nr_socket boot option to
> > rewrite NR_SOCKETS if the default it not correct.
> 
> These two would be fall back options when nothing else can be found
> to make this work.
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel