Announcement

Collapse
No announcement yet.

Linus Torvalds Demotes "FORCE_NR_CPUS" Embedded Linux Option To Avoid Confusion

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linus Torvalds Demotes "FORCE_NR_CPUS" Embedded Linux Option To Avoid Confusion

    Phoronix: Linus Torvalds Demotes "FORCE_NR_CPUS" Embedded Linux Option To Avoid Confusion

    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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Wow, umm, isn't "force" a bad word? Maybe we should use "politely suggest" instead to appease the marketing teams of our corporate overlords?

    (Sorry I resisted typing this for 3 hours but the alcohol is making me unable to resist shitposting)

    Comment


    • #3
      Originally posted by Ironmask View Post
      Wow, umm, isn't "force" a bad word? Maybe we should use "politely suggest" instead to appease the marketing teams of our corporate overlords?

      (Sorry I resisted typing this for 3 hours but the alcohol is making me unable to resist shitposting)
      No, haven't you heard? "The force is female" now.

      Comment


      • #4
        I'm disappointed by this. I use a fair number of quad core processors and smaller VMs and they won't be upgraded beyond 2/4/8 CPU for the life of the service, so it seems a reasonable optimisation to me - not just for size (though I do like to keep my boot device and memory usage small), but potentially performance too.

        I guess this is just going to become another patch I need to carry, like getting rid of ext4 projid-related code to reduce struct inode size so you can fit more in a slab.
        Last edited by GreenReaper; 19 June 2024, 04:05 AM.

        Comment


        • #5
          Where do I go to complain?

          Comment


          • #6
            Originally posted by GreenReaper View Post
            I'm disappointed by this. I use a fair number of quad core processors and smaller VMs and they're not going to be upgraded beyond 8 CPU for the life of the service, so it seems a reasonable optimisation to me - not just for size (though I do like to keep my boot device and memory usage small), but potentially performance too.

            I guess this is just going to become another patch I need to carry, like getting rid of ext4 projid-related code to reduce struct inode size so you can fit more in a slab.
            from the man himself :
            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.
            feel free to tell them about your use case, they're asking for input for a reason, if enough of people like you show up with interest maybe they'll keep it around in some way.

            Comment


            • #7
              Well I don't really feel strongly enough to post, but I don't fully understand the issue.
              If you compile your own kernel you can get many config options wrong, not just this one. This does not even seem the most obscure you may get wrong.
              I might have understood the reasoning to not take the optimization once initially proposed. But since it's already there, well, if your kernel is badly configured your system doesn't work. It's not something people does by mistake when trying to lower their music volume. Changing it now seems more confusion than it is worth.

              The underlying problem might be the "expert" mode having become meaningless. This might call to take more into account what distros make (why they need to turn on things that upstream thinks that they are for experts). But there'll always be diversity in distros, so maybe that's unavoidable. Then maybe some infrastructure changes to warn more clearly about expert mode or allow distros to specify non expert alternatives known to work together with expert optimized configs or something. But it really seems more trouble than it is worth. You can't really police who considers themselves experts, or which distros consider their users expert enough or their configs not mean for non-expert users to alter...

              Am I just too insensible for nowadays ?

              Comment


              • #8
                Well, if they really want to stop misuse of the option, perhaps converting the warning to a BUG_ON would be a solution. Although it might potentially result in more error reports, too, at least in the short term.

                Comment


                • #9
                  Could I optimize for 16 cores and then still run this on a 4 core CPU?

                  Comment


                  • #10
                    Originally posted by Anux View Post
                    Could I optimize for 16 cores and then still run this on a 4 core CPU?
                    That's pretty much the case that caused the crash, trying to read per-CPU data for a CPU that isn't there. Also bear in mind if it's the number of "CPU" that includes SMT/HyperThreading (and so if you disable it in the BIOS you have changed your CPU configuration).

                    Incidentally there seems to be a patch for the bug now.
                    Last edited by GreenReaper; 19 June 2024, 04:46 AM.

                    Comment

                    Working...
                    X