Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

phoronix.com

Post reply on HN
Print view View original

31–40 of 114 posts

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#31

Post by pixl97 »

rwmj wrote: post #26
bonzini wrote: post #6

This was known. https://lwn.net/Articles/765837/ reports 21% performance impact and the plan was to handle STIBP as an opt-in security feature. I am not sure why that was not furthered in the patches that have actually been committed to Linux, as I did not follow them closely.

Apparently the way to turn this and other mitigations off is the following mouthful: pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier Would it make sense to have a single flag to "run insecure but fast" that we can use on pure development machines, test servers and the like? My Intel development server only runs code I choose.

Hey boss, I don't understand why the code works in devel but fails in production?

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#34

Post by janoc »

_cs2017_ wrote: post #3

1.3-1.4x slowdown is a lot more than I expected (I know it's for synthetic benchmarks but still...) Can someone explain (or link to an article) how a tweak to HT branch prediction heuristic can have such a huge impact on performance?

It is unlikely the branch prediction heuristics that is the problem (that in the Intel's microcode).

The problem is in the mitigations necessary to make it impossible/more difficult to exploit these side channel attacks. And that is costly because memory and needs to be moved around constantly. So that adds a ton of extra overhead whenever a context switch is made.

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#37

Post by xxpor »

rayiner wrote: post #33

I don't like how these Scepter mitigations are being rolled out with no cost/benefit analysis. On a client machine, I'd rather just disable Javascript than pay a 30-50% performance penalty for mitigating these vulnerabilities.

Do you expect Grandpa to do that analysis? The mitigations are probably behind KCONFIG flags anyway.

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#38

Post by stefan_ »

rayiner wrote: post #33

I don't like how these Scepter mitigations are being rolled out with no cost/benefit analysis. On a client machine, I'd rather just disable Javascript than pay a 30-50% performance penalty for mitigating these vulnerabilities.

A system running a browser probably has other problems, but just take every supercomputer ever or the vast majority of embedded systems.

Running other peoples code (on other peoples machines) is a cloud thing, but they have an iron grip on the kernel and other software.

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#39

Post by CamperBob2 »

rayiner wrote: post #33

I don't like how these Scepter mitigations are being rolled out with no cost/benefit analysis. On a client machine, I'd rather just disable Javascript than pay a 30-50% performance penalty for mitigating these vulnerabilities.

I would rather wait for reports of dangerous JavaScript exploits in the wild, myself. Considering that no real-world exploits of Spectre and related attacks have actually been reported, the odds that I'll fall victim to such an exploit without hearing about it in plenty of time to mitigate it are in the millions to one.

Instead, everyone has to pay the performance tax proactively, regardless of their individual threat model. That is not how this sort of thing should be handled.

Post reply on HN