Announcement

Collapse
No announcement yet.

AMD Retpoline Benchmarks From FX To Threadripper & EPYC

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

  • AMD Retpoline Benchmarks From FX To Threadripper & EPYC

    Phoronix: AMD Retpoline Benchmarks From FX To Threadripper & EPYC

    For those curious about the performance impact of the Retpoline patches as found in the latest Linux 4.15 kernel, here are some benchmarks on an assortment of old and new AMD Linux systems...

    http://www.phoronix.com/scan.php?pag...ux-4.15-FX-Zen

  • #2
    Cool, and people should check for info like this:

    Code:
    > cat /sys/devices/system/cpu/vulnerabilities/*
    Not affected
    Vulnerable
    Vulnerable: Minimal AMD ASM retpoline
    First is meltdown, second spectre _v1 vs and third spectre_v2. Third one is if you build kernel with older compiler, you are protected minimally which means from asm only but still claimed vulnerable , while if with GCC 8 and with right switch (and probably microcodes, but not sure in this) that line should say Mitigation: Full AMD retpoline or full generic if you happen to select that, etc...
    Last edited by dungeon; 01-16-2018, 03:30 PM.

    Comment


    • #3
      I see more full system recompiles of Gentoo coming... *sigh* With the new mitigation technologies built into compilers. Oh, well, it's not that we just compiled a ton of things twice.

      Anyway, these HW bugs happened and we got to act. Luckily my AMD and older VIA,... boxes are not or only mildly affected and these Retpoline changes don't seem too harsh (besides that one ThreadRipper benchmark with the readings). And over time there will probably be a few optimizations. So I'm kinda looking forward to these kernel patches.
      Stop TCPA, stupid software patents and corrupt politicians!

      Comment


      • #4
        If using retpoline renders indirect branch speculation useless, I don’t understand why you just don’t implement / use IBRS, which doesn’t disable speculation, but prevents from being victim of indirect branch predictor poisoning from outside the kernel.

        retpolines are a clever hack, but very ugly as a solution.

        Comment


        • #5
          Originally posted by Adarion View Post
          I see more full system recompiles of Gentoo coming... *sigh* With the new mitigation technologies built into compilers. Oh, well, it's not that we just compiled a ton of things twice.
          Fortunately I'm just finishing up my profile-17 migration, and have done nothing about the profile-71.1 yet. I think I'll just hang loose a bit and recompile for both at the same time. Besides, profile-17.1 isn't stable yet. Wait... Does profile-17.1 require a full recompile, too?

          Comment


          • #6
            So the default is "spectre_v2=auto", which -seems- sensible. Is it smart enough to see that it's on an AMD machine and pick "retpoline,amd"? When it's on an Intel machine will it pick "retpoline" or "retpoline,generic"?

            Comment


            • #7
              So my FX is more powerful after the fix? That's an interesting turn of events.

              Comment


              • #8
                Originally posted by Redi44 View Post
                So my FX is more powerful after the fix? That's an interesting turn of events.
                I noted the same on the 1800X - it gains a small performance boost. that's cool

                Comment


                • #9
                  Originally posted by phred14 View Post

                  Fortunately I'm just finishing up my profile-17 migration, and have done nothing about the profile-71.1 yet. I think I'll just hang loose a bit and recompile for both at the same time. Besides, profile-17.1 isn't stable yet. Wait... Does profile-17.1 require a full recompile, too?
                  Not stable yet. And I'll keep my hands off it, considering the (few though) problems I had during 13.x -> 17.0 transition. (few things did not compile) And we just had gcc 5.4.0 with c++11 which needed a complete recompile that year, then, in late fall the 6.4.0/PIE/c++14 thing with the next recompile.
                  I mean, I got 8 to 10 systems with Gentoo, and for most I am chroot compiling on the big bix. This isn't really fun to see the next complete --emptytree recompile happening. (command line only systems may be okay, but I got at least 4 systems with KDE or XFCE and thus full DE stack plus browsers (partially -bin, though) and libreoffice and stuff. Some aren't available as -bin - and qt*, gtk:2/gtk:3, wkgtk, boost/+~build, llvm/clang/gcc/stuff take really take long to compile.
                  It's a bit painful, but then, nobody there could have seen these HW issues coming.

                  I'll lean back from my only mildly affected position and wait until things are stable, the first fallout has gone and then I'll give it a go.
                  Stop TCPA, stupid software patents and corrupt politicians!

                  Comment


                  • #10
                    Originally posted by Adarion View Post
                    And we just had gcc 5.4.0 with c++11 which needed a complete recompile that year, then, in late fall the 6.4.0/PIE/c++14 thing with the next recompile.
                    I mean, I got 8 to 10 systems with Gentoo, and for most I am chroot compiling on the big bix.
                    I never did a full recompile for the move to gcc-5.4 - I don't remember seeing that in the instructions. My systems seemed to run just fine. It's moot now, because I've just finished a full recompilation with gcc-6.4.

                    I have six systems running Gentoo, and do it all native on each machine. I'm thinking of moving some of my infrastructure to Pi-type stuff in the near future, and for that I'll likely use some sort of build-host.

                    Comment

                    Working...
                    X