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

81–90 of 114 posts

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

#81

Post by monocasa »

hermanradtke wrote: post #20
vbezhenar wrote: post #15

Earlier quoted context omitted.

That's not really clear from the article, but I suspect that performance drop is from multithreaded software. And sure, if you are observing performance degradation with hyper-threading, there's 0 reason to keep it enabled. OpenBSD guys suggest to turn it off after all.

The article claims a 30% perf slowdown with PHP. The majority of PHP workloads are single threaded. That causes me to suspect this impacts single core workloads too.

That's interesting. 30% is generally the back of the envelope number for what hyperthreads get you in a OoOE core.

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

#82

Post by 64738 »

NewsAware wrote: post #53
frostburg wrote: post #49

Earlier 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

Exactly... they're running on XP so it's all good

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

#83

Post by azahk »

School-Cotton wrote: post #67
azahk wrote: post #59

Earlier quoted context omitted.

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?

Linux would have beaten Windows if it wasn't for that.

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

#84

Post by KozmoNau7 »

paavoova wrote: post #9

This is somewhat unfortunate for older-gen hardware. The difference between chugging-along but usable vs 20% reduced performance is crippling.

I am a little fearful at how hard it will impact my X220i with its Sandy Bridge i3. Hopefully it won't be too bad.

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

#85

Post by black-tea »

azahk wrote: post #83
School-Cotton wrote: post #67

Earlier quoted context omitted.

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?

Linux would have beaten Windows if it wasn't for that.

But at what cost? I don't want to run Linux with non-free drivers. That's not the point.

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

#86

Post by azahk »

black-tea wrote: post #85
azahk wrote: post #83

Earlier quoted context omitted.

Linux would have beaten Windows if it wasn't for that.

But at what cost? I don't want to run Linux with non-free drivers. That's not the point.

That's cool. On the other hand, I would love to have a stable API for drivers so manufacturers can release their drivers. That has been taken from me, and now Linux will never be a real choice for me without good GPU drivers, as an example.

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

#88

Post by rwmj »

crustycoder wrote: post #48
rwmj wrote: post #26

Earlier 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.

This alphabetti spaghetti of boot flags is getting ridiculous, there seems to be no central list anywhere, just random snippets across the web. Why is there not a Linus rant when you really need one? :-(

To be fair there is a list, although as you say the flags themselves are pretty random. Of course they can't be easily changed because that would break everyone's boot environment.

https://github.com/torvalds/linux/blob/master/Documentation/...

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

#89

Post by int0x80 »

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.

It makes sense (to me) and it has been discussed. I don't know what was the conclusion though.

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

#90

Post by black-tea »

gizmo686 wrote: post #73
School-Cotton wrote: post #67

Earlier quoted context omitted.

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?

The main downside is that a bad/buggy driver can take down the entire system.

That's a problem with the architecture but a reason for having the drivers in the kernel. It means such a case will be handled as a regression and fixed as opposed to the driver just never being available again.
Post reply on HN