A post merge-window change that landed in Linux Git overnight ahead of tomorrow's Linux 7.2-rc2 release is bumping the default limit on the number of supported CPU cores for RISC-V 64-bit. Now by default Linux will support up to 256 cores with RISC-V 64-bit kernel builds.

Up to now RISC-V 64-bit has maintained a NR_CPUS value of 64 for the number of CPU cores to be supported. But merged to Git for Linux 7.2 that default threshold has been bumped to 256 cores/threads. The NR_CPUS value in turn impacts the size of various static memory allocations and as that number goes higher does slightly increase kernel memory consumption. Meanwhile over on Linux x86_64, most distribution vendor kernels with MAXSMP enabled see NR_CPUS up at 8192 to deal with today's high core count AMD and Intel server processors. AArch64 (ARM64) even has 512 for its NR_CPUS value or 2048 for LoongArch.

Raising the NR_CPUS for RISC-V came at the request of SpacemiT. The commit bumping the limit explained:

"SpacemiT has already produced a 80-core RVA23 RISC-V server, and going further back, the dual-socket SG2042-based Sophgo Pisces has 128 cores (although that had some issues achieving mainline support). Therefore, an NR_CPUS of 64 is not enough.

Raise default NR_CPUS to 256 for 64BIT (when !RISCV_SBI_V01, since very old firmware can't support more than 64 cores). The number was picked as a power of two that is at least double the known max. I believe this should be the right balance between not wasting too much memory and not having to touch this too often.

Ubuntu has already been shipping NR_CPUS=512 for riscv64. We have also been testing NR_CPUS=256 internally at ISCAS and found negligible performance impact and no ill effects."

The only surprising bit is that it was accepted post-merge-window by Linus Torvalds, granted, it shouldn't have any real regression risk.

That NR_CPUS increase was merged to Linux Git as part of this week's RISC-V fixes.