NR_CPUS parameter pin in config

Hello! We have an issue on platform with two AMD EPYC 9654 96-Core Processor on ArchLinux (SMT enable, 384 threads).

The problem is that lscpu does not display all threads.

root@archlinux ~ # lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         52 bits physical, 57 bits virtual
  Byte Order:            Little Endian
CPU(s):                  320
  On-line CPU(s) list:   0-319

NUMA:                    
  NUMA node(s):          2
  NUMA node0 CPU(s):     0-95,192-287
  NUMA node1 CPU(s):     96-191,288-319

While investigating the problem, we found the NR-CPUS parameter pin to be 320 threads. This value now is hardcoded in linux config file.

root@archlinux ~ # uname -r
6.11.6-arch1-1
root@archlinux ~ # zgrep -w CONFIG_NR_CPUS /proc/config.gz  
CONFIG_NR_CPUS=320
root@archlinux ~ #

Other linux distributions such as Ubuntu do not have this problem:

root@HWDEV-645-4GEN-AMD:~# lscpu
Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Byte Order:                         Little Endian
Address sizes:                      52 bits physical, 57 bits virtual
CPU(s):                             384
On-line CPU(s) list:                0-383


NUMA node0 CPU(s):                  0-95,192-287
NUMA node1 CPU(s):                  96-191,288-383

Please, raise the value of this parameter, or bring it to the view of the original configuration.

Otherwise, please describe the reason why only 320 cores are possible now.

added priority3-normal severity4-low statusunconfirmed labels

assigned to @freswa, @anthraxx, @toolybird, and @gromit

changed the description

changed the description

added scopebug statusconfirmed labels and removed statusunconfirmed label

assigned to @heftig, @dvzrv, and @tpowa and unassigned @freswa, @toolybird, and @gromit

closed with commit a91b7acb

CONFIG_MAXSMP selects CONFIG_CPUMASK_OFFSTACK, which is liable to make the kernel slower. Do we actually need to support 8192 CPUs, or 512 would be enough for known real-world usage cases?

Do you have benchmarks?

added resolutioncompleted label

mentioned in commit mcoffin/aur-linux@a91b7acb