[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |