On Fri, Jul 03, 2020 at 07:38:14PM +0200, Peter Zijlstra wrote: > On Fri, Jul 03, 2020 at 07:09:41PM +0200, Uladzislau Rezki wrote: > > On Fri, Jul 03, 2020 at 06:56:27PM +0200, Peter Zijlstra wrote: > > > On Fri, Jul 03, 2020 at 05:57:49PM +0200, Uladzislau Rezki wrote: > > > > Hello, folk. > > > > > > > > I have a system based on AMD 3970x CPUs. It has 32 physical cores > > > > and 64 threads. It seems that "nr_cpu_ids" variable is not correctly > > > > set on latest 5.8-rc3 kernel. Please have a look below on dmesg output: > > > > > > > > <snip> > > > > urezki@pc638:~$ sudo dmesg | grep 128 > > > > [ 0.000000] IOAPIC[0]: apic_id 128, version 33, address 0xfec00000, GSI 0-23 > > > > [ 0.000000] smpboot: Allowing 128 CPUs, 64 hotplug CPUs > > > > > > This is your BIOS saying it needs 128 ids, 64 of which are 'empty'. > > > > > > I have a box like that as well, if it bothers you boot with: > > > "possible_cpus=64" or something. > > > > > OK, i got it. I thought that "cpu_possible_mask" strictly follows > > the rule: the number of CPUs in a system that physically are present. > > Nah, it's based on ACPI (SRAT IIRC) tables. The case of > over-provisioning is useful for systems that support physical hotplug, > but I've seen boards without that capability do it too. > > Just chalk it up to the foibles of BIOS. > Yes, i see that such information is propagated by the BIOS to the kernel, at least for x86 systems. Thad sad if i have single socket system then we do not have any physical hotplug ability, thus there is no need in over-provisioning. Agree that it can be hard to fix, since all that depends on ACPI interface. Like you stated in another mail. -- Vlad Rezki
