Announcement

Collapse
No announcement yet.

OpenSUSE's Spectre Mitigation Approach Is One Of The Reasons For Its Slower Performance

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

  • OpenSUSE's Spectre Mitigation Approach Is One Of The Reasons For Its Slower Performance

    Phoronix: OpenSUSE's Spectre Mitigation Approach Is One Of The Reasons For Its Slower Performance

    OpenSUSE defaults to IBRS for its Spectre Variant Two mitigations rather than the Retpolines approach and that is one of the reasons for the distribution's slower out-of-the-box performance compared to other Linux distributions...

    http://www.phoronix.com/scan.php?pag...lt-Spectre-Hit

  • #2
    Typo:

    Originally posted by phoronix View Post
    As for openSUSE changing their defaults, at least from the aorelinked mailing list discussion

    Comment


    • #3
      I don't like how performance driven some people think and how also tests on Phoronix are tending a lot toward only performance.

      I am missing an explanation between IBRS and Retpoline in the article as much as I missed information about why several distributions were faster or slower in the past.

      But it was clear that this kind of "pressure" would be applied on more secure but slower approaches since the default behavior of the Kernel is one of the riskier options.

      One shouldn't forget that there is more than just raw performance in terms of results per time. Performance also includes how risky it is to use a certain product for a certain purpose.

      Comment


      • #4
        Having switched several machines over to OpenSUSE Leap a bit ago after running a popular rolling distro for several years, this is a great find and thanks to those reporting it.

        I had some initial reservations on switching to OpenSUSE, since OpenSUSE generally performs slower in Phoronix Benchmarks. But, I figured some kernel tweaks would maybe help.

        I roll my own kernels, so I didn't see this particular issue. The kernels I compiled are using Mitigation: Full generic retpoline .

        The other changes I made from the stock OpenSUSE kernel config to match what I typically run:

        OpenSUSE Leap default value --> changed value

        CONFIG_HZ_250=y --> CONFIG_HZ_1000=y
        CONFIG_NO_HZ_IDLE=y --> CONFIG_NO_HZ_FULL=y
        CONFIG_PREEMPT_NONE=y --> CONFIG_PREEMPT_VOLUNTARY=y
        # CONFIG_SCHED_AUTOGROUP is not set --> CONFIG_SCHED_AUTOGROUP=y



        With these changes, I haven't seen any perceivable performance loss running OpenSUSE as my primary desktop and on some servers.
        Last edited by mgmartin; 04-14-2019, 12:09 PM.

        Comment


        • #5
          Originally posted by oooverclocker View Post
          I don't like how performance driven some people think and how also tests on Phoronix are tending a lot toward only performance.

          I am missing an explanation between IBRS and Retpoline in the article as much as I missed information about why several distributions were faster or slower in the past.

          But it was clear that this kind of "pressure" would be applied on more secure but slower approaches since the default behavior of the Kernel is one of the riskier options.

          One shouldn't forget that there is more than just raw performance in terms of results per time. Performance also includes how risky it is to use a certain product for a certain purpose.
          While this reasoning might be true in general for server environments, in this case both IBRS and Retpolines are both Spectre v2 security mitigation strategies and from what I've read and seen so far Retpolines is the more performant and just as secure alternative of these two. At least Intel thinks so: https://software.intel.com/security-...echstories.org (p. 20 = summary). Hence there is no security penalty for going with more performance here.
          Last edited by ms178; 04-14-2019, 02:15 PM.

          Comment


          • #6
            Originally posted by mgmartin View Post
            Having switched several machines over to OpenSUSE Leap a bit ago after running a popular rolling distro for several years, this is a great find and thanks to those reporting it.

            I had some initial reservations on switching to OpenSUSE, since OpenSUSE generally performs slower in Phoronix Benchmarks. But, I figured some kernel tweaks would maybe help.

            I roll my own kernels, so I didn't see this particular issue. The kernels I compiled are using Mitigation: Full generic retpoline .

            The other changes I made from the stock OpenSUSE kernel config to match what I typically run:

            OpenSUSE Leap default value --> changed value

            CONFIG_HZ_250=y --> CONFIG_HZ_1000=y
            CONFIG_NO_HZ_IDLE=y --> CONFIG_NO_HZ_FULL=y
            CONFIG_PREEMPT_NONE=y --> CONFIG_PREEMPT_VOLUNTARY=y

            With these changes, I haven't seen any perceivable performance loss running OpenSUSE as my primary desktop and on some servers.
            I also run a Laptop with openSUSE Tumbleweed, a custom Kernel config and with the Spectre/Meltdown mitigations disabled. I'd also turn off debug symbols and change the CPU governor to performance and use blk-mq as I/O scheduler.

            Comment


            • #7
              Originally posted by ms178 View Post

              I also run a Laptop with openSUSE Tumbleweed, a custom Kernel config and with the Spectre/Meltdown mitigations disabled. I'd also turn off debug symbols and change the CPU governor to performance and use blk-mq as I/O scheduler.
              Good points I missed to call out! -- I use blk-mq (standard now with a 5.0.x kernel), set schedutil as the governor, and set CONFIG_DEBUG_KERNEL=n .

              Comment


              • #8
                Then the OpenSuse's guide must have a hardware recommendation for AMD microprocessors.

                Comment


                • #9
                  so opensuse is full of bullshit too, just like openbsd

                  Comment


                  • #10
                    x86 is garbage not useful beyond arch-tied proprietary PC applications, thankfully it is now obsolete and it is dying along with Intel, we will have ARM as de facto arch in Apple macbooks by 2020, the last slice of x86 market share. AMD is OK and x86 in consoles is OK.

                    Comment

                    Working...
                    X