Linus Torvalds himself has turned to demoting this CONFIG_FORCE_NR_CPUS option further to avoid confusion.
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.
Which led Linus Torvalds to reflect: Yeah, that warning very much means “you aren’t running a valid config”.
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.
In turn Torvalds then pushed 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.
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.
The original article contains 568 words, the summary contains 171 words. Saved 70%. I’m a bot and I’m open source!
Actual tldr seems to be:
There was an option to hardcode cpu count intended for fixed devices as in embedded systems where you might compile the kernel specifically for your device. This made it slightly smaller and faster.
People did dumb things with this and used it so wrong that the toy was taken away.
Very uninteresting article, super disappointing Lemmy even showed it.
This is the best summary I could come up with:
Linus Torvalds himself has turned to demoting this CONFIG_FORCE_NR_CPUS option further to avoid confusion.
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.
Which led Linus Torvalds to reflect: Yeah, that warning very much means “you aren’t running a valid config”.
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.
In turn Torvalds then pushed 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.
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.
The original article contains 568 words, the summary contains 171 words. Saved 70%. I’m a bot and I’m open source!
This is an awful summary. Why is it getting upvoted?
Noone noticed because noone reads the articles.
We really need an autodr bot that justs pastes the text verbatim like:
This is the best copy I could come up with:
[…]
The original article contains 568 words, the copy also contains 568 words. Saved 0%. I’m a bot and I’m open source!
I’d much prefer that. Sometimes the autotldr does a great job but most of the time it deletes key sentences to understanding
Actual tldr seems to be: There was an option to hardcode cpu count intended for fixed devices as in embedded systems where you might compile the kernel specifically for your device. This made it slightly smaller and faster. People did dumb things with this and used it so wrong that the toy was taken away.
Very uninteresting article, super disappointing Lemmy even showed it.