The Linux kernel "FORCE_NR_CPUS" Kconfig option has been around a few years to force the number of CPU cores the kernel expects in order to allow for better compiler optimizations. When building a kernel targeted for a specific device/platform with a given number of CPU cores, the compiler can optimize CPU mask routines and shrink the size of the resulting kernel image rather than having to accommodate up to a dynamic upper-limit for the number of CPU cores to be found at boot time. Linus Torvalds himself has turned to demoting this CONFIG_FORCE_NR_CPUS option further to avoid confusion.

The FORCE_NR_CPUS Kconfig build-time option has really been about those doing targeted Linux kernel builds for specific platforms and really wanting to optimize the resulting kernel size. Back in 2022 when introduced when using FORCE_NR_CPUS=y with a default NR_CPUS=4 value for targeting a 4-core platform, the kernel image saved... 46KB. Not much except for extreme embedded scenarios with limited resources.

But when the number of CPUs of the system doesn't match the forced number of CPUs for such kernel builds, problems can arise. It was today [1]reported of a kernel crash when the forced number of CPUs does not match the booted number of CPUs. Which led Linus Torvalds to [2]reflect :

Yeah, that warning very much means "you aren't running a valid config".

That said, I think FORCE_NR_CPUS was a mistake. It improves bitmask op code generation a tiny bit (quite a lot actually on a micro level, but not necessarily hugely noticeable in the big picture) by making nr_cpu_ids a compile-time constant, but it's such a special-case embedded-only (or "tuned for my particular machine") option that it's just not worth it.

It's behind "EXPERT", and while that *should* mean that it doesn't get enabled by default, I think the fact that many distros enable EXPERT in their default distro config means that the whole thing has lost all meaning.

If you start out with the distro config, you're magically an expert. And when everybody is an expert, no one is.

In turn Torvalds then pushed [3]this commit to further restrict FORCE_NR_CPUS:

Hardcoding the number of CPUs at compile time does improve code generation, but if you get it wrong the result will be confusion.

We already limited this earlier to only "experts" (see commit fe5759d5bfda "cpumask: limit visibility of FORCE_NR_CPUS"), but with distro kernel configs often having EXPERT enabled, that turns out to not be much of a limit.

To quote the philosophers at Disney: "Everyone can be an expert. And when everyone's an expert, no one will be".

There's a runtime warning if you then set nr_cpus to anything but the forced number, but apparently that can be ignored too and by then it's pretty much too late anyway.

If we had some real way to limit this to "embedded only", maybe it would be worth it, but let's see if anybody even notices that the option is gone. We need to simplify kernel configuration anyway.

This change is now in Linux 6.10 Git ahead of Linux 6.10-rc5 next Sunday.

So for now the CONFIG_FORCE_NR_CPUS is further restricted while waiting to see if anyone objects to the change... If no concerns are raised this option might eventually just be removed from the mainline Linux kernel or otherwise finding an approach to better handle embedded-only kernel build options for those wanting to save kilobytes on their kernel image sizes.



[1] https://lore.kernel.org/all/20240618105036.208a8860@rorschach.local.home/

[2] https://lore.kernel.org/all/CAHk-=whzYU-tOzxKg4f_i9G+D9No_r=uZ6g11w5UjkgfRZDf5g@mail.gmail.com/

[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d272dd1b3430bb31fa30042490fa081512424e4