Hi, I've tested on ESXi version 5.5 and it seems OK. - VM1: Ubuntu 14.04, kernel 3.19 ---> OK 3 cpu dirs, possible = 0-2 - VM2: Centos7, kernel 3.10 ---> OK 8 cpu dirs, possible = 0-7
I tried another MacBook with Fusion, same issue happens, the cpu[0-9] dirs are not equal to /sys/devices/system/cpu/possible Regards, William On Mon, Aug 1, 2016 at 9:30 AM, William Tu <u9012...@gmail.com> wrote: >>> And in my /sys/devices/system/cpu, I have cpu0 and cpu1, >>> kernel_max = 63 >>> possible = 0-63 >>> present = 0-1 >> >> glibc is doing >> ls -d /sys/devices/system/cpu/cpu* >> http://osxr.org:8080/glibc/source/sysdeps/unix/sysv/linux/getsysstats.c?v=glibc-2.14#0180 >> And /sys/devices/system/cpu/possible shows 0-63 while only two dirs 'cpu0' >> and 'cpu1' >> are there?! > > yes, that's right. > I only have cpu0 and cpu1 directories, while 'possible' shows 0-63. > >> If my understanding of cpu_dev_register_generic() in drivers/base/cpu.c >> is correct the number of 'cpu*' dirs should be equal to possible_cpu. >> Could you please debug why is that the case, because then it's probably >> a bug on the kernel side. > > Thanks, I will do it. > >> I think it's correct for glibc to rely on the number of 'cpu*' dirs. >> Did you boot with possible_cpus=64 command line arg by any chance? >> > No. > >>> So sysconf simply reads these entries configured by kernel. Looking at >>> kernel code, "arch/x86/configs/x86_64_defconfig" sets >>> CONFIG_NR_CPUS=64, and later on set_cpu_possible() is called at >>> arch/x86/kernel/smpboot.c, which parses the ACPI multiprocessor table >>> and configured new value. Based on these observations, I think >>> different hypervisor may have different ways of emulating ACPI >>> processor table or BIOS implementation thus these values differ. >> >> What behavior do you see in ESX ? >> btw, rhel7 ships with nr_cpus=5120 and ubuntu default is 256, >> so this lack of acpi in vmware fusion will lead to possible_cpu=5120, >> a lot of pain in per-cpu allocator and linux VMs will not be happy. >> I think vmware has to be fixed first regardless of what we find >> out about 'cpu*' vs /sys/devices/system/cpu/possible >> > > Thanks, I will debug it and update when I have more info. > Regards, > William
