Slashdot Mirror


How Do Spectre/Meltdown Fixes Affect The Linux Kernel? (phoronix.com)

"Using the newly minted Linux 4.19 feature code, fresh benchmarks were carried out looking at the performance cost of Spectre/Meltdown/Foreshadow mitigations on Intel Xeon v. AMD EPYC CPUs," writes an anonymous Slashdot reader: Workloads affected by these CPU vulnerabilities mainly deal with I/O and frequent kernel calls while CPU bound tests are still found to be minimally impacted. When toggling these mitigations on Linux 4.19, Intel Xeon CPUs were found to be 10~15% slower with the default kernel while AMD EPYC CPUs dropped to about 5% slower.

29 comments

  1. As expected by Anonymous Coward · · Score: 0, Troll

    It is not a slowdown, it is removing an undue [broken/illegal/dangerous] speedup ;-)

    You can, of course, disable the mitigation. Just don't do it on anything processing external network packets, etc.

    1. Re:As expected by gweihir · · Score: 2, Insightful

      Indeed. And this partially explained why Intel was ahead of AMD speed-wise. They played fast and loose and f*** the customer.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  2. EPYC problem by Anonymous Coward · · Score: 0

    The only problem with AMD processors is they don't implement transactional memory operations. When they do, I will switch.

    1. Re:EPYC problem by Tough+Love · · Score: 4, Informative

      The only problem with AMD processors is they don't implement transactional memory operations.

      I can understand your concern if you need this for research, but as an optimization, transactional memory has so far proved pretty underwhelming.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    2. Re:EPYC problem by dmpot · · Score: 4, Informative

      The only problem with AMD processors is they don't implement transactional memory operations.

      Aside some very specific use cases, transactional memory does not offer much in terms of performance. Moreover, transactional memory helps a lot with Timing Side Channel Attacks against the kernel. For example: https://www.blackhat.com/docs/...

    3. Re:EPYC problem by gweihir · · Score: 0

      On the plus-side, they have far better CPU-CPU interconnect than Intel and always had.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    4. Re:EPYC problem by Anonymous Coward · · Score: 1

      AMD doesn't even make true multi core CPUs. It's just a bunch of half cores glued together with a hackneyed bus to connect them. I will stick with Intel because they have true multi core CPUs where the cores are all full cores and directly tied together as one CPU.

  3. Haven't noticed much by Anonymous Coward · · Score: 0

    I have not noticed any slowdowns myself. I have seen examples of obvious slow down's in testing. But they probably are not significant enough to be noticed by a user. I know people who have opted not to install firmware and even some who have opted out of OS updates. I guess you take your chances and hope for the best or play it safe and maybe have a bit slower PC. For myself, I don't really have any tasks that has ever required every bit of performance. So for myself a 10 to 15% reduction is not a big deal.

    1. Re: Haven't noticed much by Anonymous Coward · · Score: 0

      This sounds like a shill for Intel. No consumer would be okay with a processor that performs 10-15% under what he selected.

    2. Re: Haven't noticed much by Tough+Love · · Score: 3

      Basically, this completely erases Intel's single thread advantage over AMD. I am sure that Intel will fix their speculative execution blunders in some future processor generation, I suspect it can be fixed without any slowdown, just re-engineering and maybe a bunch more transistors in the cache and dispatch logic. But by the time Intel does fix it AMD will already be shipping 7nm processors. So I don't see Intel getting back into the high end processor lead any time soon.

      It's a one-two-three whammy for Intel. Almost starting to feel sorry for them. Almost.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    3. Re: Haven't noticed much by Anonymous Coward · · Score: 0

      What makes you think it can be fixed without any slowdowns?

      The entire purpose for creating these gaping holes - especially Meltdown - was to eke out more performance at the cost of security. It was a deliberate trade-off. And now you're claiming this can be fixed without paying the cost? Do you believe in magic?

    4. Re:Haven't noticed much by Zontar+The+Mindless · · Score: 1

      Try compiling a few editions of a popular database server every day. You'll notice.

      --
      Il n'y a pas de Planet B.
    5. Re: Haven't noticed much by thegarbz · · Score: 1

      What are you talking about. The CPU still performs exactly what they selected. The user chooses to run expensive code that mitigates security vulnerabilities that don't affect most use cases.

      Personally I don't have any Spectre / Meltdown mitigations enabled. The security tradeoff isn't worthwhile. Plus if I really wanted security I would print off my packets on the printer, carry them to the computer on the other end of the internet and scan them in again. But ... lag.

    6. Re: Haven't noticed much by thegarbz · · Score: 2

      So I don't see Intel getting back into the high end processor lead any time soon.

      Why are you implying they aren't in the lead? Users can chose optimised code paths at the expense of security. We do this all the time and the trade off is in terms of risk vs reward. Just like when you log into your online bank instead of walking to the branch and manually doing your banking you make the same trade-off.

      Users don't need to run Spectre / Meltdown mitigations, not only from a choice point of view, but also because the risk profile is so incredibly low for the vast majority of use cases it doesn't actually make any sense for a typical user. End result: Speed.

      If my workloads weren't often multi-threaded then Intel would still be the performance king, but lets face it... my next CPU will be a Ryzen.

    7. Re: Haven't noticed much by Highdude702 · · Score: 1

      The slow downs are from klunky software fixes, as soon as they engineer new chip design to mitigate this, they can get the speed back if they're skilled.

  4. Re: Protect yourself with APK Hosts File Engine... by Anonymous Coward · · Score: 0

    I use os/2 you insensitive clod.

  5. Oh yeah, that shit by Anonymous Coward · · Score: 0

    The short of the current consensus is that everything about Intel's x86 now sucks, forever. Pointer-chasing has become expensive to the detriment of vast swathes of system code, and just about all of application code. System calls now cost the same as they would in 32-bit 4G/4G setups, i.e. as much as a context switch but also some trampoline overhead.

    And don't get me fucking started on Spectre. You need a crack team of leethaxxers born for the job to even begin to test whether a given binary is vulnerable to a given sequence of Spectre gadgets and their primary invocation pathway (i.e. ROP or some such). There aren't enough of those to support compiler tuneups across the industry (starting from even GCC!), so the current magic bullets come at a steep cost and are gonna be broken for about a decade still.

    Guess they should've given some thought to security back when they were taping out the Pentium Pro, eh.

  6. Code Analysis by Anonymous Coward · · Score: 0

    if (cpu == intel) {
                    if (microcode_version != current) {
                                      crash_cpu();
                    } else {
                    }
                    disable_l1_cache();
                    disable_l2_cache();
                    disable_l3_cache();
                    disable_isntr_cache();
                    disable_data_cache();
                    disable_tlb_cache(); // this is why benchmarking is prohibited -- don't tell anyone
                    if {ultra_secure_mode == 1 && num_cores > 1 && customer_has_paid_us_money(lookup_microcode) );
                    for (i=1;i=core_count;i++) {
                                  disable_core(i);
                    disable_smm_mode();
                    disable_secret_cpu_used_for_management_engine();
                    disable_management_engine();
                    }
    }

    it's "only" a 15% performance penalty, just those little caches are disabled, nothing to worry about, except if you go to "ultra_secure" mode, than the performance penalty jumps.

    1. Re: Code Analysis by Anonymous Coward · · Score: 0

      Your code can't compile - syntax error.

      You compare against the magical value 1.

      Rejected.

    2. Re:Code Analysis by Anonymous Coward · · Score: 0

      disable_secret_cpu_used_for_management_engine();
      disable_management_engine();

      Oh God, I need the source code (or even a compiled blob) of this so badly...

  7. Re:Protect yourself with APK Hosts File Engine... by Zontar+The+Mindless · · Score: 2

    Where's the BeOS port you promised us in 1997?

    --
    Il n'y a pas de Planet B.
  8. Re:Slashdot users LOVE the Win64 version... apk by Anonymous Coward · · Score: 0

    I believe I am in love with Hosts files. I feel a bit of.. a bit of pee coming up, oh yes. A small amount, a droplet, of pee is now running down my legs. This is so invigorating! Bring me back to life, Hostfile engine! Another droplet from the fountain of life, no, many droplet. Verily a stream of urine is now soaking my pants. This is an amazing day.

  9. Re:Protect yourself with APK Hosts File Engine... by Anonymous Coward · · Score: 0

    You're out of luck. However, AFAIK, a Haiku port is upcoming.

  10. I M P E R S O N A T I N G ME ? apk by Anonymous Coward · · Score: 0

    Don't you have anything better to do than IMPERSONATE me?

    APK

    P.S.=> Seriously... apk

  11. I am APK the LORD of HOSTS by Anonymous Coward · · Score: 0

    I am APK the great "LORD of HOSTS", a.k.a. AlecStaar from ArsTechnica or Alexander Peter Kowalski.

    See subject & APK Hosts File Engine 2.0++ 64-bit for Linux h t t p : / / I . a m . a . f u c k i n g / a s s h o l e . r e t a r d . z i p (remove spaces between characters & download).

    I am the godlike creator of various GUI front-ends for other people's configuration files.

    When presented with facts I rebut them with wild speculations, false support, and out of context quotes

    All of my accomplishments revolve around me being proven to be an annoying spamming asshole

    See me be proud of my inability to be a functional adult

    Bask in my debilitating mental illness

    Hear me tell stories about me living large drinking miller lite in my ramshackle duplex with a roommate at age 54.

    You must be conspiring with the Jews and Soros if you disagree with me

    Mistaking mockery and parody for impersonation is how I think people flatter me because I can't possibly understand that they detest me.

    Watch as I claim I am world class and a winner but in reality I am a fucking loser.

    Witness my descent into madness

    APK

  12. Talk to me about OpenSSH not the kernel by Seven+Spirals · · Score: 1

    Local exploits are a lot harder to pull off than remote exploits. The primary gatekeeper of the worlds IT device is Secure Shell. I just have one simple question: If this shit is so catastrophic and bad like we've been hearing, then where the fuck are the OpenSSH remote root exploits? Bullshit flag thrown. Now point me to the exploit code that returns a root prompt and I'll drink your security Chicken Little kool-aid. Until then *yawn*.