Intel was supposed to have 20-30% advantage on single thread performance over Amd. Now I guess single or multiple thread AMD is better on Linux. I don't know why it makes me giddy thinking of the coming consumer wars between the 2.
Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
61–70 of 114 posts
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#62Big win for AMD!!!
It's times like this when I'm glad I went with a Ryzen chip instead of whatever Intel has on offer. Not only do I get a ton of cores, but now my chip performs better than the competition!
The only real problem I've had has been with soft lockups, which I was able to solve by disabling a power saving feature on the CPU. If AMD doesn't mess things up, they can really catch up to Intel in the next couple years while Intel is working on fixing their issues.
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#63Think I will wait at least 1-2 more years for all this to shake out before I buy a new computer.
All the security changes, plus 7nm chips should be widely available and will hopefully bring a price decrease.
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#64Earlier quoted context omitted.
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?
You're implying (with unnecessary snark) that:
1. Development machines should be configured identically to production machines. (Do you install a GUI and development tools on your production servers?) Occasional differences in behavior between development/production are par for the course, and is why staging environments are commonly used.
2. The mitigations affect the execution result of code likely to be developed/executed at a typical software shop. AFAIU the attacks are timing-based, and won't affect valid code that's not specifically looking to exploit them.
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#65Earlier quoted context omitted.
Would you like a nuclear powerplant to be ran with this kind of approach to safety? Given the amount of possible targets and how unreliable people can be at assessing what risk they're exposed to, having mitigation active by default is obviously the only sane answer.
Somehow I doubt nuclear power plants run (unmodified) Linux kernels released in the last 5 years
Psst, every machine on the Internet must now be hardened to conform to nuclear and aerospace industry standards. So sayeth the Priesthood of Infosec. Haven't you heard?
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#66In case people don't like the headline style (leaving out the reference to the answer), the answer given at the end of the article is new Spectre mitigations. We new that speculative-execution mitigations would sometimes reduce performance, and evidently they do. :-(
And yet, surprisingly, no references to "420" being an appropriate number for slow response time.
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#67Why is so much code being added to a kernel? <terms of lines of code changed with more than 354 thousand lines of new code added at the end of October when this merge window opened.
Someone once had the great idea that drivers should be in the same codebase as the kernel. Crazy, I know.
It doesn’t seem crazy to me that something that runs in kernel mode and uses kernel APIs should be in the kernel codebase. What are the downsides?
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#68I'm just sitting here waiting for all the security fiasco to stop ruining performance for ridiculous unpractical attacks. Just a matter of time, the pressure for better performance in a world where moore's law is getting stuck will eventually cause every sane person to throw these ridiculous patches out of the window. If the choice is between unsecure but fast to secure and slow, the default should be fast. Let appli…
These attacks aren’t impractical at all. The very first announcement of spectre and meltdown came with trivial sample code.
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#69Earlier quoted context omitted.
Then in which architecture?
They still sell Itanian, I don’t think Spectre/Meltdown affect that product line.
*Itanium, and they would likely suffer from the same attacks (maybe not due to being a completely different architecture, but being from thw same company, not sure if there isn't crosspolination between the two), but dont think anyone has looked at them due to small market pressense.
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#70I 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 have been meaning to ask about this. How vulnerable are desktops to these exploits?