[–]▶ No.998486>>998512 >>998831 >>999261 >>1001140 [Watch Thread][Show All Posts]
The new Spectre patches in Linux 4.20 absolutely destroys Intel. As usual AMD is mostly unaffected because they didn't trick consumers by sacrificing security for speed for over 20 years. Interestingly this is while Stress-NG socket activity for Intel increased by 40% and context switching increased by 7% compared to 4.19. AMD got a 6% increase in socket activity and a 55% increase in context switching compared to 4.19.
Will the onslaught of new Spectre vulnerability discoveries every month finally be the death blow to Intel we've been hoping for? I'm sure even the enterprise is starting to wake up to this and will be buying loads of Zen 2 servers.
>This ranged from Rodinia scientific OpenMP tests taking 30% longer to Java-based DaCapo tests taking up to ~50% more time to complete to code compilation tests taking measurably longer to lower PostgreSQL database server performance to longer Blender3D rendering times. That happened with a Core i9 7960X and Core i9 7980XE test systems while the AMD Threadripper 2990WX performance was unaffected by the Linux 4.20 upgrade.
>Those affected systems weren't high-end HEDT boxes but included a low-end Core i3 7100 as well as a Xeon E5 v3 and Core i7 systems. AMD systems though still didn't appear impacted. Those tests also found workloads like the Smallpt renderer to slowdown significant, PHP performance to take a major dive, and other scientific workloads like HMMer also faced a major setback compared to the current Linux 4.19 stable series.
>An intentional kernel change for better mitigating against Spectre is the latest reason why the Intel Linux performance is much slower.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.20-Initial-Slowdowns
https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect
▶ No.998488>>998512
The Stress-NG benchmarks.
▶ No.998500
Pathetic... what else can I say?
▶ No.998512>>998544 >>998547 >>998699 >>998701 >>999257 >>1001486 >>1002500
>>998486 (OP)
>>998488
>Intel absolutely destroyed by new Spectre patch
More like
>Monolithic Kernels absolutely destroyed by Spectre patch for Intel
Wanglows, BSD, and OSX all have Spectre patches but they didn't suffer nearly the performance impact, this is more a Linux issue than anything else. Monolithic kernels tend to require a lot of memory access from usermode to kernel mode.
▶ No.998540>>999203
anyone know what kernel configs these are so you can turn this shit off?
▶ No.998544>>998546
>>998512
>Wanglows, BSD, and OSX all have Spectre patches but they didn't suffer nearly the performance impact
>BSD
Very interesting. Quality post.
▶ No.998546>>998548
>>998544
I know that you know that BSD is just shorthand for modern BSDs
▶ No.998547>>998548 >>998549 >>998834 >>1001115
>>998512
>this is more a Linux issue than anything else.
Wew.
>Wanglows, BSD, and OSX all have Spectre patches
Do you think Judensoft and Goyple fully patched the flaws or do you think they applied simple bandaids?
Do you think FagBSD has enough technical contributors to fully patch the flaws since taking the CoC?
I've heard from numerous Jewtel fanboys that they bought Jewtel chips because supposedly Jewtel was hiring the top dawgs to hand design every aspect of their processors where as AMD used cookie cutter software wizards to populate their chips.
▶ No.998548>>998551
>>998546
I wasn't referring to that. I'm not that autistic. It's just interesting how BSD is also one of the better offs because of the kernel.
>>998547
BSDs don't share their entire kernel. Each implementation is still pretty different. BSDs are whole OSs.
Unlike Linuxdistros which are all the same kernel slapped together with different default software and repos.
▶ No.998549
>>998547
>Do you think FagBSD has enough technical contributors to fully patch the flaws since taking the CoC?
IIRC they were already half-protected from Meltdown/Spectre because they had Page Table Isolation enabled by default and their system was already designed around its potential performance impact. Windows was a similar story
▶ No.998551>>998553
>>998548
The performance impact comes purely from usermode programs that need to access kernel mode memory. If a usermode program only wants to access usermode memory, then there is no issues, if kernel mode programs need to access kernel memory, then there are also no issues generally speaking. This is largely a design problem as far as performance impact is concerned.
▶ No.998553
>>998551
>kernelmode usermode problem
Terry was right again.
▶ No.998573>>998579
Aren't Intel's 2019 CPUs said to ship with hyper-advanced Spectre+Meltdown software mitigations instead of fixed hardware?
Did they take notes from Lockheeb's F-35 project management when designing consumer ASICs?
▶ No.998579
>>998573
the patches are the mitigation, unless they do some management engine fuckery (which would annoy people even more)
▶ No.998627>>998639 >>999257
Year of the rsic-v cpu!!!!!!
▶ No.998639
>>998627
more like never. Haven't even seen a proper RISC-V pc yet. More like tons of shitty binary blob SoCs
▶ No.998699
>>998512
BSD is monolithic, retard.
▶ No.998701>>998703
>>998512
BSD doesn't have this issue because they're 1-10 years behind on patches. It's probably still vulnerable.
▶ No.998703>>998704
>>998701
Good job revealing you don't know what a BSD is
▶ No.998704>>998714
>>998703
Good job revealing you don't know what a BSD is
▶ No.998714
>>998704
Good job revealing you don't know what a BSD is
▶ No.998796>>998797 >>998833 >>998872
More lije YEAR OF THE POWER9 TALOS SYSTEM when?
Also, ttanks to Lord Theo's prescient foresight, OpenBSD is arguably the most secure in the face of Intelaviv vulnerabilities.
▶ No.998797
>>998796
>OpenBSD
Most /tech/ people already said that OpenBSD is more secure than other popular OSs.
▶ No.998821
I'm not a Intel shill but obviously the performance impact will be improved before release
▶ No.998831>>998855
>>998486 (OP)
>Will the onslaught of new Spectre vulnerability discoveries every month finally be the death blow to Intel we've been hoping for?
No, there are endless gov't contracts for new, horrifically insecure computers.
▶ No.998833>>999206
>>998796
Power9 would be the answer if Talos wasn't acting like kikes and trying to rip off would-be buyers.
▶ No.998834>>998835
>>998547
I hate Jews too but your speech is becoming cryptic
▶ No.998835
>>998834
Agreed. Seems like fud with no purpose
▶ No.998855
>>998831
Intel is an American company that actually fabs in the USA still. There are hundreds of fabs in America but they're mostly owned by non-American companies. As long as this remains Intel will have a monopoly in the Federal sector.
▶ No.998872>>999053 >>999260 >>1002504
▶ No.998877>>998884
These vulnerabilities are really getting out of hand. Are modern CPU architectures really that much of a mess?
▶ No.998884>>999002
>>998877
Yes, many modern architectures, regardless of ISA, are total clusterfucks. ARM and x86 architectures seem to be the worst offenders. POWER has had very few problems. SPARC, MIPS, and m68k based processors are still clean as fuck.
▶ No.999002>>999247
>>998884
The older ARM stuff is fine. I have a dual core Cortex-A7 that by design is not vulnerable to any of the Meltdown/Spectre bugs. It's also a lot cleaner and open than x86 (u-boot firmware, no blobs anywhere), and it's much less expensive than POWER (which itself was affected by those bugs). I don't see anything else actually *good* on the market that makes me want to buy it. Even the POWER stuff has made compormises for speed, and that's not a place I want to go.
▶ No.999053
>>998872
That's a whole different degree of mitigation. So far on x86 it's not possible to enable full kernel+user mitigation - the best they can do is kernel mitigation. If kernel+user mitigation was added to x86 microcode you'd see a similar (probably worse) performance impact.
▶ No.999203
>>998540
pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier
Only add this to your kernel cmdline if you like your computer's anus stretched extra wide.
▶ No.999206
>>998833
>rip off
How much do you think it costs to design and start production of such complex hardware? They don't have the customer numbers of ASUS or Supermicro to amortize it over, faggot.
▶ No.999247>>999332
>>999002
>Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17
Not fine
▶ No.999257
>>998512
Who the fuck do you think Intel makes most of their money from? The server market. Guess how much of the server market is running Linux.
>>998627
I physically fucking laughed. Thank you, anon.
▶ No.999260>>999274
>>998872
This is what I expect from every OS, and I will assume that each OS which performs better than this with compromised hardware is in fact still compromised.
▶ No.999261>>999262 >>999268 >>999501
>>998486 (OP)
>be me
>just bought a used xeon workstation
>see this horse shit
>feelings immense anger and disappointment
Eh, at least I'm only out $350. This might be okay if I'm able to disable a few of the security fixes.
▶ No.999262>>999264
>>999261
>Buying Jewtel for Loonix
▶ No.999264>>999266
>>999262
>dirt cheap
>lots of RAM
>ECC RAM
>lots of L3 cache
>lots of cores
>lots of SATA connections
>lots of USB ports
The only AMD equivalent I know of is Epyc workstations and they're expensive as fuck, and I'm a poorfag.
▶ No.999266>>999272
>>999264
Fair points, but
>dirt cheap
>pays $350
I got mine for 50$. I used Craigslist, I'm guessing eBay and the like are more expensive.
▶ No.999268>>999272
>>999261
Bought a used xeon server just last year. at least it's still a decent NAS
▶ No.999272
>>999266
Yeah, but did yours come with 32GB RAM and an almost new 1TB SSD? Mine did. I bought it from a guy I know who cleans out old office buildings. Most of the time they're told to throw these machines in the trash so he sticks a few in his truck. Machines with similar specs go for like $800+ on ebay, so it wasn't a bad deal at all, aside from the Intel bugs of course.
>>999268
How's that on your electricity bill? I'm using a Core2 Duo laptop for that myself.
▶ No.999274
>>999260
Very specific hardware and software combination benchmark is what you expect for the two operating systems which work on it. Mkay do you work for IBM by any chance?
▶ No.999332
>>999247
I mean more like the pre-Cortex chips, like those in the NDS for example. Even those are good enough to do interesting things with (pic related).
I bought the Cortex-A7 board specifically because it's one of the few of those that doesn't do out-of-order execution and speculation. I'm probably going to get another board with four A7 cores, or maybe even an octacore, although the downside with those is they need big heatsink and/or fan in order to run at max clockspeed.
▶ No.999478>>999480
>Linux 2 years ago was faster than OpenBSD by about 20%
>OpenBSD pushes mitigations to a paranoid level, takes another 20% hit in performance
>Linux finally patches vulns and is now slower than OpenBSD while ignoring fundamental flaws which can affect other non-Intel machines
hahahaha
▶ No.999480>>999568
>>999478
Not for Ryzen though, and OpenBSD disables SMT on Ryzen systems... the AMD implementation is always encrypted (Intel's HT was a hack that got around the IBM patents).
▶ No.999501
>>999261
>This might be okay if I'm able to disable a few of the security fixes.
??????????
▶ No.999568
>>999480
>OpenBSD disables SMT on Ryzen systems
You can easily re-enable it though.
▶ No.1000231>>1001080
Bump, should I get AMD for my datacenter? it's looking like even Gartner is suggesting it.
▶ No.1001063>>1001078 >>1001095
So how do we disable these patches in ganoonix and windows?
▶ No.1001078>>1001081
>>1001063
In GNU/Linux it can be disabled with a kernel boot param in grub. On Windows you can either edit the registry manually or use a tool called "InSpectre" to check if its enabled and have it disable it for you if you want.
▶ No.1001080
>>1000231
If you have some clout, you should look into the possibility of getting early Zen2 based EPYC CPUs, probably mid 2019, if it fits your project schedule. They'll go in the same SP3 motherboards so you can effectively do all the hard work ahead of time. If you're just a small fry or looking into building a datacenter tomorrow, the gains are far less significant.
EPYC 7000s will be cheaper than Intel's offering for sure both in initial costs and performance/$ over time, but if you want to do HPC stuff they're practically useless. They excel at distributed independent mid-range workloads. So things like hosting VPCs or serving webshit.
▶ No.1001081>>1001086
>>1001078
Awesome, and what about in BIOS? Probably none?
▶ No.1001086>>1001326
>>1001081
You can flash an older bios revision if one exists for your board. There are also forums out there dedicated to making patched BIOS' for various options not included by default on many different boards, including shit like overclocking on unsupported processors if you really want to go there.
▶ No.1001095>>1001096
>>1001063
This patch has been disabled in all stable kernels offically.
>Revert "x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation"
>It's not ready for the stable trees as there are major slowdowns
>involved with this patch.
▶ No.1001096>>1001330
▶ No.1001115
>>998547
What a clever post, I see what you did there. 10/10
▶ No.1001140>>1001167
>>998486 (OP)
>the death blow to Intel we've been hoping for
>we've been hoping for
>we
Try using a non-n00b OS, faggot.
Intel even on bloated Windoze still obliterates AMD post-patch.
▶ No.1001167
>>1001140
Imagine being this mentally crippled. Can't find your big boy words?
▶ No.1001326
>>1001086
Interesting. I guess on the newer CPUs there's no going back to pre-patch.
▶ No.1001330>>1001399
>>1001096
http://lkml.iu.edu/hypermail/linux/kernel/1811.2/01328.html
"This was marked for stable, and honestly, nowhere in the discussion did I see any mention of just *how* bad the performance impact of this was.
When performance goes down by 50% on some loads, people need to start asking themselves whether it was worth it. It's apparently better to just disable SMT entirely, which is what security-conscious people do anyway.
So why do that STIBP slow-down by default when the people who *really* care already disabled SMT?
I think we should use the same logic as for L1TF: we default to something that doesn't kill performance. Warn once about it, and let the crazy people say "I'd rather take a 50% performance hit than worry about a theoretical issue".
Linus"
▶ No.1001399
>>1001330
For most workloads SMT actually hinders performance anyway, at least on Windows.
▶ No.1001486>>1001945
>>998512
>Windows, BSD, and OSX are not monolothic
▶ No.1001945
>>1001486
They all use microkernels
▶ No.1002500>>1008605
>>998512
This. The issue is that Linux is a shitfest coded by trannies and homosexual communists. The chip made by high agency whites and asians is not the problem.
▶ No.1002504
>>998872
Kernel protection seems decent and kernel/user protection isn't even enabled on x86 yet. Hell, in some places, that's better than x86
▶ No.1003048>>1004375
>be linux
>updates cause worse performance
>become windows
Sad!
▶ No.1004375
>>1003048
MS is literally on the board of the Linux Foundation now.
▶ No.1008571
Got my new kernel boiz, it is slower when doing certain tasks, by a lot.
▶ No.1008605>>1008607
>>1002500
Well those high agency whites and asians better learn how to start submitting kernel patches to the most important server os out there if they want their chips to perform what they promise
▶ No.1008607
>>1008605
They're working on fixing the ME exploits first. National security and all that.