Why 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.
Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
51–60 of 114 posts
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#52Think I will wait at least 1-2 more years for all this to shake out before I buy a new computer.
You'll get a much better deal anyway if you do that. I never buy the current generation of hardware. Much better value per dollar to buy one or two generations old. Unless you absolutely need bleeding edge performance.
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#53Earlier quoted context omitted.
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 threa…
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
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#54Why 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.
Drivers
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#55Earlier quoted context omitted.
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 threa…
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.
Sorry, but that's my call, not yours. My computer is not a nuclear power plant.
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#56No mention of the fact that AMD seem unaffected?
It's mentioned in two different places in the article.
Indeed, though the headline seems kind of odd to me given that it's specifically an Intel problem as far as I can tell, it'd be nice to have _some_ mention in there (even if people following this can guess anyway).
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#57Earlier 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.
Sorry, but that's my call, not yours. My computer is not a nuclear power plant.
The Linux team also needs to make a call on the kernel they maintain. You can always choose to stick with an older kernel or even patch out the fixes if you like.
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#58Earlier 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.
Sorry, but that's my call, not yours. My computer is not a nuclear power plant.
Are there any of those changes you can't disable for your computer? I thought all(?) of them were behind flags, since different hardware needs different sets.
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#59Why 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.
Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower
#60Is there a comparison table of CPU vulnerabilities? I would like to know which CPU has the least vulnerabilities or the best performance after patching. From what I have read so far is seems that AMD CPUs have had the fewest vulnerabilities/slowdowns? But I can't be sure since I haven't seen a complete comparison (including these new vulnerabilities).
I don't know of any comparison table. There are two family of vulnerabilities at play when talking about Spectre and co:
- The general Spectre family, which affects most (if not all) CPUs built with speculative execution.
- Meltdown and L1TF, which only affects Intel CPUs due to them delaying security checks until after speculation has taken place.
AMDs, ARMs, etc. that use speculative execution are going to be vulnerable to at least some variant of Spectre (there are 4 variants known right now). ARM published a table[0] explaining which of their CPUs are vulnerable to which variants. I'm not aware of any such table for Intel or AMD.
Microsoft published some interesting tables[1] explaining which mitigation protect against which Spectre variant, and under which thread models they operate.
[0]: https://developer.arm.com/support/arm-security-updates/specu...
[1]: https://blogs.technet.microsoft.com/srd/2018/05/21/analysis-... (scroll down for the tables)