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

101–110 of 114 posts

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

#101

Post by manquer »

CyberShadow wrote: post #64
pixl97 wrote: post #31

Earlier quoted context omitted.

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/…

try convincing a corp sec dept in large org to sign off on disabling anywhere.

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

#102

Post by rleigh »

64738 wrote: post #82
NewsAware wrote: post #53

Earlier quoted context omitted.

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

When I went to Sellafield they had Win3.1 on the fuel rod chopping machine in the reprocessing plant (admittedly in '97!)

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

#103

Post by jcelerier »

BeeOnRope wrote: post #80
_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?

The impact is big enough that one would suspect the microcode simply disables indirect branch prediction, so you pay a 16-20 cycle penalty per branch. Indirect branches just aren't frequent enough to explain such a regression via say a simple reduction in prediction resources. I can test it once I get the new firmware.

> Indirect branches just aren't frequent enough

aren't vtable calls / function pointer calls indirect branches ?

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

#104

Post by opsroller »

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? :-(

lsmod

modinfo ${somemodule}

man lsmod man modinfo

This is elementary level linux, you should know this.

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

#105

Post by BeeOnRope »

jcelerier wrote: post #103
BeeOnRope wrote: post #80

Earlier quoted context omitted.

The impact is big enough that one would suspect the microcode simply disables indirect branch prediction, so you pay a 16-20 cycle penalty per branch. Indirect branches just aren't frequent enough to explain such a regression via say a simple reduction in prediction resources. I can test it once I get the new firmware.

> Indirect branches just aren't frequent enough aren't vtable calls / function pointer calls indirect branches ?

Yes, they are (at least when the compiler cannot devirtualize them) - but they make up a fairly small fraction of the total instructions in a typical program - and probably very small in something like cinebench, which also showed a big regression.

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

#106

Post by jcelerier »

BeeOnRope wrote: post #105
jcelerier wrote: post #103

Earlier quoted context omitted.

> Indirect branches just aren't frequent enough aren't vtable calls / function pointer calls indirect branches ?

Yes, they are (at least when the compiler cannot devirtualize them) - but they make up a fairly small fraction of the total instructions in a typical program - and probably very small in something like cinebench, which also showed a big regression.

> but they make up a fairly small fraction of the total instructions in a typical

but if their cost increases by a large factor... besides, in any large compiled program, the core would certainly be based around some kind of programmable pipeline, and these would generally be implemented like this unless they wrote their own JIT compiler.

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

#107

Post by BeeOnRope »

jcelerier wrote: post #106
BeeOnRope wrote: post #105

Earlier quoted context omitted.

Yes, they are (at least when the compiler cannot devirtualize them) - but they make up a fairly small fraction of the total instructions in a typical program - and probably very small in something like cinebench, which also showed a big regression.

> but they make up a fairly small fraction of the total instructions in a typical but if their cost increases by a large factor... besides, in any large compiled program, the core would certainly be based around some kind of programmable pipeline, and these would generally be implemented like this unless they wrote their own JIT compiler.

Yes - but for their cost to increase by such a large factor, the only obvious thing I can think of is that their prediction is disabled.

I didn't follow your comment about a "programmable pipeline". I don't think many or any of the Phoronix benchmarks are based on a pipeline with indirect branches at their core.

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

#108

Post by reality_czech »

bronzeage wrote: post #45

I'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…

I'm sitting here waiting for you to realize "unsecure" is not a word.

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

#109

Post by chrisseaton »

pixl97 wrote: post #31
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.

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

Not everyone has ‘production’. A mathematician running experiments only locally, for example.

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

#110

Post by jcelerier »

BeeOnRope wrote: post #107
jcelerier wrote: post #106

Earlier quoted context omitted.

> but they make up a fairly small fraction of the total instructions in a typical but if their cost increases by a large factor... besides, in any large compiled program, the core would certainly be based around some kind of programmable pipeline, and these would generally be implemented like this unless they wrote their own JIT compiler.

Yes - but for their cost to increase by such a large factor, the only obvious thing I can think of is that their prediction is disabled. I didn't follow your comment about a "programmable pipeline". I don't think many or any of the Phoronix benchmarks are based on a pipeline with indirect branches at their core.

> I don't think many or any of the Phoronix benchmarks are based on a pipeline with indirect branches at their core.

I think a bunch are. e.g. for instance FFMPEG / libavfilter which is basically a node graph set up at runtime. Don't know for cinebench since it's closed source, but Blender present in the benchmarks is also based around a nodal rendering architecture. Stuff like PHP / CGI also heavily depend on function pointers for their behaviours - PHP with its plugin architecture, and CGI where all web requests go through FPs : https://github.com/php/php-src/blob/master/main/fastcgi.c#L8....

Post reply on HN