>>> On 06.05.15 at 09:05, <chao.p.p...@linux.intel.com> wrote: > On Tue, May 05, 2015 at 11:43:57AM +0100, Jan Beulich wrote: >> >>> On 05.05.15 at 12:25, <chao.p.p...@linux.intel.com> wrote: >> > 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. >> >> But that's the case regardless of how many CPUs we actually boot. >> Or what am I overlooking here? >> > So now we have two CPU numbers. One is the original processor count we > got from MADT, the other one is nr_cpu_ids we actually use. > > To calculate nr_socket correctly, the former is what we need. While what > I concern here is even for the original processors we got from MADT, > can we trust they are always continuous?
Right, there's no such guarantee. We may be making assumptions on them being not too sparse elsewhere, but ... > I'm not sure for it. But if they are not, then the above calculation is > bogus. ... for the case here this indeed may need to be done in a more robust way. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
