Announcement

Collapse
No announcement yet.

AMD Adding STIBP "Always-On Preferred Mode" To Linux

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

  • AMD Adding STIBP "Always-On Preferred Mode" To Linux

    Phoronix: AMD Adding STIBP "Always-On Preferred Mode" To Linux

    Initially during the Linux 4.20 kernel merge window with the STIBP addition for cross-hyperthread Spectre V2 mitigation it was turned on by default for all processes. But that turned out to have a sizable performance hit so the behavior was changed to only turn it on for processes under SECCOMP or when requested via the PRCTL interface. However, AMD is landing a patch that for select CPUs will have an always-on mode as evidently that's preferred for some AMD processors...

    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
    I have to wonder why it is preferred. Are some processors more exposed? Or do AMD processors not suffer as much with the facility turned on?

    Micheal you kinda left us high and dry here with no explanation.

    Comment


    • #3
      Originally posted by wizard69 View Post
      I have to wonder why it is preferred. Are some processors more exposed? Or do AMD processors not suffer as much with the facility turned on?

      Micheal you kinda left us high and dry here with no explanation.
      I get the impression from the AMD quote in the article that turning the flag on and off constantly may be more expensive than just leaving it on all the time for certain AMD processors. Does anyone know which AMD CPUs prefer this feature to be always-on?

      Comment


      • #4
        Originally posted by Mr.Radar View Post
        Does anyone know which AMD CPUs prefer this feature to be always-on?
        Can a CPU have a different CPUID depending on microcode? If yes then we need to wait for new microcode to surface.

        If not, then it may be something only for new CPUs.

        Comment


        • #5
          I read that removing Hyper-Threading would be enough to deal with Spectre (and skip all mitigations). Having so much cores today, I wonder if that solution is best when compared to multiple patches in kernel. As using threading [SMT], would no longer be so good. Public already having 8 to 32 cores available now. Looking ahead it seems the home user will be able to have more cores in the near future.

          I ask here because Phoronix is so great with testing. ¿Is it still worthy having 16 threads with 8 cores, instead of 8 threads 8 cores?

          I though about that for batch processes. To pin a process with cpu affinity to one vCore to ensure real cores available and the performance is consistent. I would like to know others opinion on the subject.

          Comment


          • #6
            Originally posted by wizard69 View Post
            I have to wonder why it is preferred. Are some processors more exposed? Or do AMD processors not suffer as much with the facility turned on?

            Micheal you kinda left us high and dry here with no explanation.
            Because I don't even have the info myself yet on an explanation.
            Michael Larabel
            https://www.michaellarabel.com/

            Comment


            • #7
              Originally posted by jordi.ferran View Post
              I read that removing Hyper-Threading would be enough to deal with Spectre (and skip all mitigations). Having so much cores today, I wonder if that solution is best when compared to multiple patches in kernel. As using threading [SMT], would no longer be so good. Public already having 8 to 32 cores available now. Looking ahead it seems the home user will be able to have more cores in the near future.

              I ask here because Phoronix is so great with testing. ¿Is it still worthy having 16 threads with 8 cores, instead of 8 threads 8 cores?

              I though about that for batch processes. To pin a process with cpu affinity to one vCore to ensure real cores available and the performance is consistent. I would like to know others opinion on the subject.
              HT is still worthwhile... I did some benchmarks recently you should be able to find with searching.
              Michael Larabel
              https://www.michaellarabel.com/

              Comment


              • #8
                Originally posted by Michael View Post
                HT is still worthwhile... I did some benchmarks recently you should be able to find with searching.
                Agreed, if performance is the principal concern, HT does deliver a meaningful improvement. If security is the principal concern however, HT should be disabled in the BIOS - especially if you have an older processor for which there is no new microcode available.

                Comment


                • #9
                  Originally posted by torsionbar28 View Post
                  If security is the principal concern however, HT should be disabled in the BIOS - especially if you have an older processor for which there is no new microcode available.
                  I agree entirely. It is best to disable HT. Except for FreeBSD users, where the operating system does already do this for the users.
                  I have disabled HT/SMT in each machine and also counter the deficit with as many cores as possible. For simple desktop computers the performance decrease is not noticeable in common use cases - for gaming it might even lead to noticeably more consistent frame times.

                  Comment


                  • #10
                    Originally posted by wizard69 View Post
                    Micheal you kinda left us high and dry here with no explanation.
                    I've got a wild educated guess: It's possible AMD wants to flag enterprise-targeted processors with the always-on flag. It makes sense to me that someone running a Ryzen R5 or similar on their own desktop won't need the same total protection as someone using a EPIC processor to run 30 VMs for completely different clients who would need protection from the other clients. As said, it's just a guess.

                    I guess the same principle applies to Hyperthreading in general. I'd totally disable it if I was responsible for the security of a ton of servers running a bunch of virtual machines for random clients. The same security concerns don't really apply to a desktop used to play games and that kind of things.

                    Comment

                    Working...
                    X