Live data from Hacker News

Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

phoronix.com

21–30 of 114 posts

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

#21
post #17

Does the article not actually mention the reason? (I mean, I know it's STIBP, but it never says that?

it's on page two. Why a short article like this has pages though...

I saw the social buttons and assumed end of article, very bad design.

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

#23

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.

Yes, on some processors basically it's as if all userspace was recompiled to use retpolines. Enabling STIBP promises that one thread cannot influence the indirect branch predictor's operation when the sibling runs; on those processors the indirect branch predictor is completely disabled, which is an inefficient but valid way to implement STIBP semantics.

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

#24
post #17

Does the article not actually mention the reason? (I mean, I know it's STIBP, but it never says that?

it's on page two. Why a short article like this has pages though...

I was going to say because it's Phoronix, and they've traditionally had very heavy advertising, but I decided to load it up and turn off ublock to check because I haven't visited Phoronix in quite a while, and it seemed to have little to no big advertising. Nice!

Now I assume it's because while even if the textual content is quite small, all the images mean there's quite a bit of vertical length to the article. I had to scroll down quite a bit to get to the next page button. The second page is quite small though, so maybe a better page break algorithm in is order. e.g. break at size X unless total length is X*1.25, and if only two pages, try to make them somewhat even in size (erroring on the side of a larger first page).

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

#26
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.
Post reply on HN