Announcement

Collapse
No announcement yet.

64-bit ARM Linux Kernel Against CPU-Specific Optimizations: "Pretty Unmaintainable"

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

  • #21
    Originally posted by ms178 View Post

    They refuse to do so. Graysky's micro-architecture patch (that allows x86 architecture tuning) was shot down several times over the last couple of years. As a result, several distros simply use that patch in their downstream Kernel. I personally have been using that for years now.

    The reasoning was laid down by Ingo Molnar here: https://lore.kernel.org/lkml/[email protected]/

    As we have the x86-feature levels nowadays, there is an argument that concentrating on these four feature levels in the Kernel is a more maintainable base worth optimizing for.
    This is two diffrent things the arm patch is about code build into the kernel if i see it right.

    And the micro architecture patch is about how the kernel is build by the compiler, and it is simply not needed cause every user can build a custom kernel with export -march=native.

    And i doubt any mainstream distribution uses any higher than -march=x86-64-v2 maybe v3 cause it has to run on every intel/amd cpu out there if they where to build in with a vendor specific flag the kernel just wont boot cause instruction registers for that cpu type are missing on older or cross vendor cpus.

    So i claim it´s a myth.

    Comment


    • #22
      Originally posted by Volta View Post
      Open Source developers are still maintaining code that closed source dropped years ago. You're a joke.
      Are we talking about old hardware here?

      No.

      Stop making it so easy proving to the world how much of a joke you are. It's no challenge.

      Comment


      • #23
        Originally posted by AlanTuring69 View Post
        Your contributions must be invaluable to say something like that. I would like to see some of your most famous patches and some of the projects you've maintained?
        I would if it didn't tie them down to my real name.

        Comment


        • #24
          How common are 4k pages anyway? I use 64k pages on all but the tiniest ARM machines.

          Comment


          • #25
            I agree with agnostic code too.
            Think long term.
            Same should apply for risc-v.

            Comment


            • #26
              Originally posted by erniv2 View Post

              This is two diffrent things the arm patch is about code build into the kernel if i see it right.
              You are absolutely right about the patch in question which is not about architecture flags but optimizing a certain function for that specific ARM architecture. However, we can broaden the subject to CPU-specific Kernel tweaks in general to have a meaningful debate here. If Glibc found a way how to deal with CPU-specific functions, it would be great to find ways to extract the maximum amount of performance hardware has to offer in the Kernel, too? It would be my dream that we will get software someday in the future that is tuned for the specific hardware in the system to extract maximum performance (while it would be a lot of work, this is doable even today, a distro just needed to offer repos for popular CPU architectures and have a detection-mechanism in the installer).

              Comment


              • #27
                Originally posted by erniv2 View Post

                And i doubt any mainstream distribution uses any higher than -march=x86-64-v2 maybe v3 cause it has to run on every intel/amd cpu out there if they where to build in with a vendor specific flag the kernel just wont boot cause instruction registers for that cpu type are missing on older or cross vendor cpus.

                So i claim it´s a myth.
                CachyOS might not be mainstream right now, but they offer up to x86-64-v4 Kernels nowadays and detect that during installation already. At the end of the year, they'll even offer most of the Arch repos with x86-64-v4 (and I'd love to see some benchmarks vs. v3-repos and normal Arch repos to see what impact this has on performance in general).

                Comment


                • #28
                  And then there's all the ex-post-facto security mitigations N*yearly for all the various processors needing whatever kinds of "oops!" spaghetti patching to
                  cover the holes particular processor flavors leave open.

                  Originally posted by coder View Post
                  Modern CPUs are so incredibly complex that it's implausible you won't occasionally need such tweaks.

                  Comment


                  • #29
                    Originally posted by Volta View Post

                    Open Source developers are still maintaining code that closed source dropped years ago. You're a joke.
                    Come back and tell us that after connecting a QLogic QLGE card. Or 98% of the world's Android phones that use RNDIS for tethering.

                    You are a mentally challenged clown.

                    Comment


                    • #30
                      Originally posted by Weasel View Post
                      As much as I hate ARM, this does suck.

                      This is why open source maintainers are a joke.
                      What? That's a good thing.

                      ARM is already such a royal mess where mainline kernels cannot be used with almost every ARM system to date, and you want them to pull in more SoC variant-specific patches?

                      Can you imagine what will happen if, for example, board vendors like Asus, MSI etc license Intel/AMD processors, make changes to them, and then submit patches for every single change they make to the processors back to the kernel?

                      Actually, just imagine what will happen if all of them submitted requests to Microsoft to include their vendor-specific x64 optimisations and customisations into the Windows kernel. Microsoft will probably just tell them to go pound sand.

                      On the other hand, if the vendors compiled these as driver DLLs and requested Microsoft to include them with Windows, Microsoft will probably be more accommodating.
                      Last edited by Sonadow; 22 November 2023, 11:57 PM.

                      Comment

                      Working...
                      X