Announcement

Collapse
No announcement yet.

Intel's One Line Of Linux Code For Speeding-Up Sapphire Rapids On Ubuntu

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

  • Intel's One Line Of Linux Code For Speeding-Up Sapphire Rapids On Ubuntu

    Phoronix: Intel's One Line Of Linux Code For Speeding-Up Sapphire Rapids On Ubuntu

    Recently I noticed out-of-the-box on Ubuntu Linux the performance of Intel Xeon Scalable "Sapphire Rapids" processors was much improved for some workloads compared to tests done just weeks ago on the same Sapphire Rapids server. It ended up being an issue coming full-circle and ultimately boils down to one line of code added within the Linux kernel.

    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
    Way to go Michael your benchmarking is directly making FLOSS software better for everyone!

    Comment


    • #3
      Once again Phoronix proves that Linux kernel code testing not what it should and could be. This one line of code reflects PURE OMISSION by code developers.

      To paraphrase a statement I may have made in the past:

      "The Linux world--community needs to find a way to pay Phoronix to do in-depth standardized code testing for the Linux kernel. It would certainly improve the quality of Linux code by spotting performance & regression issues."

      Comment


      • #4
        Originally posted by NotMine999 View Post
        Once again Phoronix proves that Linux kernel code testing not what it should and could be. This one line of code reflects PURE OMISSION by code developers.

        To paraphrase a statement I may have made in the past:

        "The Linux world--community needs to find a way to pay Phoronix to do in-depth standardized code testing for the Linux kernel. It would certainly improve the quality of Linux code by spotting performance & regression issues."
        Why should Linux users sponsor fixing of Ubuntu's stupid choices? It was known since YEARS Ubuntu's defaults suck. I also recommend looking at Ubuntu's IO scheduler, because last time I checked it was the least optimal one. To be honest Fedora isn't much better here: 250Hz, schedutils governor (possibly worse than powersave).
        Last edited by Volta; 04 May 2023, 12:45 PM.

        Comment


        • #5
          Originally posted by Volta View Post

          Why should Linux users sponsor fixing of Ubuntu's stupid choices? It was known since YEARS Ubuntu's defaults suck. I also recommend looking at Ubuntu's IO scheduler, because last time I checked it was the least optimal one. To be honest Fedora isn't much better here: 250Hz, schedutils governor (possibly worse than powersave).
          Because Phoronix readers are supporting Michael and he likes running benchmarks to check for potential regressions. They have a trickle out effect of benefiting the entire community, including corporations, as well as little people. The benchmarks identified a hole in Intel's CPU coverage identified by Ubuntu's choice of defaults. It was a bug, bugs need to be fixed no matter who turns them up. Although given some people's attitudes, it's certainly understandable when they're ignored for being a jerk.

          Second question, data centers don't optimize for maximum performance. They optimize for maximum power savings versus practical effects of the performance trade offs. As an example, since most corporate data centers are performing web serving or web-like serving the difference of servicing requests could be (number pulled out of the air for illustration) 100 ms with performance vs. 110 ms (10% difference) with power save governor. Now, the end user isn't likely to notice a 10 ms difference in any practical situation beyond some games (and perhaps not even then). But the power difference between them for a data center can be thousands of dollars between direct power consumption and cooling power consumption. Data centers consume massive amounts of electricity and water for cooling. This is why Intel (and AMD) are actually very worried over the trend towards ARM on servers. They realize x86 can't compete in the long term because raw performance is not the overriding issue in server procurement any more and much data center software runs on ARM just as well as it does on Intel but with massive potential power and cooling savings over large fleets.

          As for the ticks timer: it doesn't do what you likely think it does. There's a lot of (very) bad advice out there telling people to increase it to maximum. Messing with it without understanding its effects on any given work load will increase power consumption but may have no discernible or negative impact on performance because the CPU is distracted by too many unnecessary servicing checks. 250 Hz is what the kernel devs had historically recommended for most work loads and that's what the distros have used as default even after the "nohz" patch. Changing expected defaults is dangerous even if the change seems innocuous enough, but this particular change wouldn't be innocuous. The ticks setting has very broad consequences and some of them may not even be immediately obvious potentially setting up anomalous and not easily diagnosed behavior.

          Comment


          • #6
            Michael

            Typo "Linux t hat make use of" should be "Linux that make use of".

            Comment


            • #7
              Originally posted by stormcrow View Post
              As for the ticks timer: it doesn't do what you likely think it does. There's a lot of (very) bad advice out there telling people to increase it to maximum. Messing with it without understanding its effects on any given work load will increase power consumption but may have no discernible or negative impact on performance because the CPU is distracted by too many unnecessary servicing checks. 250 Hz is what the kernel devs had historically recommended for most work loads and that's what the distros have used as default even after the "nohz" patch. Changing expected defaults is dangerous even if the change seems innocuous enough, but this particular change wouldn't be innocuous. The ticks setting has very broad consequences and some of them may not even be immediately obvious potentially setting up anomalous and not easily diagnosed behavior.
              Spoken like someone who has never used a 1000 Hz Linux kernel, ever:

              Meanwhile, everybody using Ubuntu Studio or anyone manually installing Canonical's "lowlatency" kernel flavor is doing absolutely fine, thank you very much!

              Also, worrying about whether the kernel is forced to tick either every 4ms or 1ms while at the same time said kernel is able to do precise scheduling/logging down to nanoseconds seems silly, at best...

              Comment


              • #8
                Those are absolutely insane differences. Wowzer.

                Comment


                • #9
                  stormcrow

                  I don't know why, but you sound like chatGPT. A lot of text without much sense. I always thought Ubuntu and Fedora are primary aimed at desktops and the fact is their default configurations are terrible for desktops.

                  It was a bug, bugs need to be fixed no matter who turns them up. Although given some people's attitudes, it's certainly understandable when they're ignored for being a jerk.
                  You don't have much clue here, either. Primarily it wasn't a bug, it was Ubuntu's choice to switch from sane defaults to this mess. Furthermore, this bug fix fixes nothing. It improves terrible situation a little.

                  Comment


                  • #10
                    These are pretty hefty performance gains, with just software - I wonder if AMD should ramp up their investments that way & then continue until they can polish Linux for every CPU as well as or even better, than the competition.

                    Comment

                    Working...
                    X