[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.