Announcement

Collapse
No announcement yet.

Don't Look For Gentoo's CPU Optimization Options To Land In The Mainline Linux Kernel

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

  • Don't Look For Gentoo's CPU Optimization Options To Land In The Mainline Linux Kernel

    Phoronix: Don't Look For Gentoo's CPU Optimization Options To Land In The Mainline Linux Kernel

    Gentoo's Linux kernel build has long offered various CPU options in allowing those building their distribution to optimize their kernel build to the CPU being used. Every so often the patch is suggested for upstreaming to the mainline Linux kernel before being quickly rejected by the upstream maintainers...

    http://www.phoronix.com/scan.php?pag...ns-Kernel-2019

  • #2
    Would be interesting to see how much of a difference these patches are making.

    Comment


    • #3
      I'd like to counter the reasoning from Ingo Molnar as shown here https://lore.kernel.org/lkml/[email protected]/

      1.) "I'm not convinced the numbers are right."

      Of course with some hard facts from benchmarking these could put the whole argument at rest, and I'd like to see hard facts here, too. The Graysky2-Repo did show some numbers already which showed some significance.

      2.) "I'm not convinced the whole concept is long term maintainable to begin with."

      I'd argue that it is, the amount of lines needed is negligable when considering the overall increase in size of the Kernel in recent years and the complexity of other features. And it's not that AMD and Intel do release a new architecture every year anymore. But even if it is considered to be too burdensome, just deprecate the options which are 10 years + x old or are not widely used or relevant any longer. Maybe there is also a more clever way than enumurating all possible CPU options by hand?

      3.) "The cost of getting optimizations wrong by going away from sane defaults is probably high as well..."

      Yes, there can be regressions due to compiler bugs or bad quality of the compiler tuning. I'd argue that people who care about the performance will notice any regressions in this area and put pressure on the compiler developers to fix these. It would also be an incentive to the CPU vendors to invest more into their compiler tuning or to see a more widespread use of that labour at all. Also, the testing infrastructure of the Linux Kernel did improve in recent years and performance regressions should be dealt with the same seriousness than security or stability issues. Just because there is the possibility of regressions doesn't justify to throw away the possible performance advantages by default in my opinion. I think with the end of Moore's law every percent of performance counts now more than ever. The shown mindset of some upstream developers doesn't further anything though. The Kernel should make it as easy as possible to configure this and let the people who set this option deal with the consequences and risks involved.

      Of course people who know how to apply the Graysky2 patch or who are able to alter the Makefiles with the appropriate flags from hand can already work around this Kernel limitation, but please, tear down these needless walls!
      Last edited by ms178; 02-23-2019, 01:32 PM.

      Comment


      • #4
        The argument that the c compiler might be buggy might apply with and without per-cpu optimisation so I only half understand how it counts against CPU optimisation.

        But the argument that it should not be enabled because it might be faulty enough to make things slower sounds a bit strange...

        Comment


        • #5
          I'm on Gentoo and I prepare my own kernel from git rather than using the package but I still apply this patch for Ryzen optimisations. They could at least add -march=native and that would work for the majority who want this with hardly any extra code. If it really does break something, there are surely plenty of existing "don't try this at home" kernel options that definitely will screw with your system.

          Comment


          • #6
            Originally posted by Chewi View Post
            I'm on Gentoo and I prepare my own kernel from git rather than using the package but I still apply this patch for Ryzen optimisations. They could at least add -march=native and that would work for the majority who want this with hardly any extra code. If it really does break something, there are surely plenty of existing "don't try this at home" kernel options that definitely will screw with your system.
            I just go inside the makefile and change the values there in the CFLAGS. Been doing this for years.

            Comment


            • #7
              Originally posted by sireangelus View Post

              I just go inside the makefile and change the values there in the CFLAGS. Been doing this for years.
              This could also be documented better, as there are several CFLAGS in several Makefiles. There is also the HOSTCFLAGS option in the top level Makefile. But I still wonder if I need to alter the Makefile in the arch/X86 folder in addition to that as well. As of late I do alter both to be sure. But as I am not an expert, this might not be the best practice.

              Comment


              • #8
                I've been using this patch for years without any ill effects, seems like a bogus reason not to include it and I'm surprised Clear Linux isn't doing something similar for their builds

                Comment


                • #9
                  If someone is going to go to all that trouble to configure and optimize their personal install why would they rely so heavily on a particular maintainers given set of CPU optimizations?

                  Comment


                  • #10
                    When I was on Slackware I configured the whole kernel specific to the system I had back then.

                    Comment

                    Working...
                    X