Diversity Strike Linux 5.0 Kernel Performance Sucks


tldr of this extensive benchmark is that linux 5.0 is performing worse in almost every metric. it's not substantial, but it's measurable.

Other urls found in this thread:



How long until they break userspace?


Linux 5 is slower thanks to new spectre/meltdown patches. That's it.
If you truly believe the only reason Linux is a quality kernel is that Linus said bad words on the mailing list you're a retard. If you think there are new "le sjw nigger tranny dindu nufin" devs you're a super retard. Absolutely nothing has changed in the dev cycle and there are no new maintainers.


If it's spectre/meltdown then AMD64 CPUs should be hit less because they mitigated some issues in hardware (which makes them slower in the first place tho).

Everyone in this thread is blaclisted and blocked from commenting or contributing on Linux. Except for this good goy

That's not how you write "they didn't have this fault".

Get fucked incels


AMD does have some spectre/meltdown problems, they don't have some others and some they do have but they're harder to exploit.

The problem doesn't just magically disappear when using their chips.
Here's some reddit thread:
And here's fefe:

Linux is just a kernel, there is no userspace in it.


AMD processors are partially affected too.

That still doesn't make not having a particular flaw into a mitigation for being flawed. Retardation with speculative execution is not some fact of life that you have to mitigate.

This. /thread.

This is a variant of other weird criticisms of non-reality:

Lol you're retarded. Of course userspace isn't in the kernel. When you accidentally drop something fragile and it breaks, do you say, "I couldn't have broken that, it wasn't a part of me."

If system calls stop working like they used to, userspace stops working like it used to. User applications and the kernel interface. That's the whole point of a kernel; it controls what all otoher programs can and cannot do. It's the reason another old school name for kernel is "supervisor," and by extension why a program that manages multiple kernels is a "hypervisor."

Here's part of Linus' own take on breaking userspace:
On Sun, Dec 23, 2012 at 6:08 AM, Mauro Carvalho Chehab wrote:>> Are you saying that pulseaudio is entering on some weird loop if the> returned value is not -EINVAL? That seems a bug at pulseaudio.Mauro, SHUT THE FUCK UP!It's a bug alright - in the kernel. How long have you been amaintainer? And you *still* haven't learnt the first rule of kernelmaintenance?If a change results in user programs breaking, it's a bug in thekernel. We never EVER blame the user programs. How hard can this be tounderstand?To make matters worse, commit f0ed2ce840b3 is clearly total and utterCRAP even if it didn't break applications. ENOENT is not a valid errorreturn from an ioctl. Never has been, never will be. ENOENT means "Nosuch file and directory", and is for path operations. ioctl's are doneon files that have already been opened, there's no way in hell thatENOENT would ever be valid.> So, on a first glance, this doesn't sound like a regression,> but, instead, it looks tha pulseaudio/tumbleweed has some serious> bugs and/or regressions.Shut up, Mauro. And I don't _ever_ want to hear that kind of obviousgarbage and idiocy from a kernel maintainer again. Seriously.I'd wait for Rafael's patch to go through you, but I have anothererror report in my mailbox of all KDE media applications being brokenby v3.8-rc1, and I bet it's the same kernel bug. And you've shownyourself to not be competent in this issue, so I'll apply it directlyand immediately myself.WE DO NOT BREAK USERSPACE!Seriously. How hard is this rule to understand? We particularly don'tbreak user space with TOTAL CRAP. I'm angry, because your whole emailwas so _horribly_ wrong, and the patch that broke things was soobviously crap. The whole patch is incredibly broken shit. It adds aninsane error code (ENOENT), and then because it's so insane, it adds afew places to fix it up ("ret == -ENOENT ? -EINVAL : ret").The fact that you then try to make *excuses* for breaking user space,and blaming some external program that *used* to work, is justshameful. It's not how we work.Fix your f*cking "compliance tool", because it is obviously broken.And fix your approach to kernel programming. Linus
It does my heart glad to see him dicking down redhat. Too bad those days are over.

Not the user you're replying to, and while it may not have been the only reason, it definitely was one of the reasons. It certainly seemed to be effective. I think the above post from the lkml is evidence of that.


This is more of the Bloatware is Proprietary phenomenon. You must accept whatever "fixes" are forced on you even if they suck. If you fork the code, you need to keep fixing bugs yourself. When code is 15 million lines, porting the bug fixes is as hard as fixing them all yourself. This is why nobody made a version of Linux that handles out of memory correctly but microkernels have all kinds of forks and reimplementations that take different directions.

That's actually a fundamental problem with the UNIX "philosophy" of files. UNIX presents the illusion that every device is a PDP-11 tape drive or typewriter, depending on whether you can seek. Instead of having APIs that reflect the behavior of the actual device, UNIX weenies shove all functionality that doesn't look like a tape drive into ioctl so they can have a "simple and elegant" and "small and consistent" interface with only hundreds of system calls instead of thousands. All of these ioctls are separate functions on other operating systems.

Because there are other error codes that can be returned by otherdrivers when this specific ioctl (VIDIOC_QUERYCTRL) is called.Let me take one step back and explain what this patch weretrying to do.What happens is that the V4L2 API is very complex (~80 ioctls).In practice, that means that two drivers implementing the APImight behave a little different than the others, with causestroubles on userspace. We're working to fix it, by testing allof them using userspace testing tools.

An example of how much ioctl sucks is that functions like "VIDIOC_ENUM_FMT" and "VIDIOC_G_JPEGCOMP" are treated as ioctls, which were originally for controlling serial typewriter-like terminals. "Not a typewriter" originally meant the ioctl was invalid. On a real OS, the purpose of a driver is to translate abstract operations into actual commands and data for the device. Instead of pretending video devices are a weird kind of typewriter, the OS would have a class of drivers for all kinds of video devices.


Subject: Small And Consistent Interface, Bah!So I'm doing this tcp/ip implementation and my advisor and Iagree that we should be binary compatible with bsd syscalls[this is kind of a traditional move around here otherwisepeople tend to ignore your work because recompiling is toodifficult]. "How are you going to handle ioctl's?" he asks."Hmm," I say, "I mapped out how I'd handle every socketsyscall except the ioctl's but how hard could that be?" Hehheh heh.Not only do you have to handle ioctl's which get calledusing the ioctl syscall. You also have to handle theioctl's that get called via the fcntl syscall and thesetsockopt syscall. Oh yeah, and then there are some fcntlioctl's that can be called by the dupx syscalls. [Let meguess, they named these syscalls dup and dup2 because theyare (a) completely redundant and (b) you are one if you usethem.]Did I forget anything?

Nobody asked for your opinion. Fuck off.


lol mauro on suicide watch

this is what made linux great
this is what linus is not doing anymore.

Are there new patches in 5.0 that can be blamed that are not in 4.20? Does this explain why 5.0 is clearly slower than 4.20?


I think this is it, but I thought there was one that was more specific that directly mentions there should be a switch to not apply the patch to amd processors.

On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen wrote:> This is a fix for Variant 2 in> googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html>> Any speculative indirect calls in the kernel can be tricked> to execute any kernel code, which may allow side channel> attacks that can leak arbitrary kernel data.Why is this all done without any configuration options?A *competent* CPU engineer would fix this by making sure speculationdoesn't happen across protection domains. Maybe even a L1 I$ that iskeyed by CPL.I think somebody inside of Intel needs to really take a long hard lookat their CPU's, and actually admit that they have issues instead ofwriting PR blurbs that say that everything works as designed... and that really means that all these mitigation patches should bewritten with "not all CPU's are crap" in mind.Or is Intel basically saying "we are committed to selling you shitforever and ever, and never fixing anything"?Because if that's the case, maybe we should start looking towards theARM64 people more.Please talk to management. Because I really see exactly two possibibilities: - Intel never intends to fix anythingOR - these workarounds should have a way to disable them.Which of the two is it? Linus


what if you disable the shitty patches? its all useless crap if you arent a vps provider

Hurd is dead.
Genode is the future

When development effort is invested into drivers. It should be easier to do because drivers are supposed to be distinct userspace binaries. It's too bad that the investment effort is so small.

Nobody asked for yours, either. Go do the same.

It's 2019, but not yet we see GNU/Hurd OS. GUN always insists that it's "Gnu/Linux" not "Linux" but actually they can't develop any OSes. They are just third-party programmers. THE REAL OS PROGRAMMERS are Linux developers.

GPL is revocable.

Ba dum tssshhh
Ba dum tssshhh

Hurd hasn't been released because A) it's garbage, and B) no one supports compiling to it, not because it is vaporware.

> opensource.com/article/19/2/cla-problems

Notice how they hand-wave it.
"Guy backed down, don't look behind this curtain"
You can revoke. Their only power against you is getting you fired/blackballed. If you do not give a shit about their "industry" you C A N fuck them completely. You have revoke and sue, and you really want to do so in a bloc with like minded, once you get the ball rolling, it's the doom of the project.

Is there a kernel option for it? Like, I can't actually flash my bootloader without booting with iomem=relaxed so maybe there's something similar for these? Unfortunately speculative execution is actually a performance necessity sometimes.

I do not want that legal precedent. Ever.


It doesn't matter if you don't want it, has been US law since the beginning of the US.

Gratuitous licenses have always been revocable at will.

everything is a configuration option at compile time, and it looks like most can be disabled at boot even if it's enabled to compile time


the fact that I had to find this shit on a zdnet article and couldn't find any official documentation is a joke. this shit is all over the place.

reddit of all places has a decent one liner to pass to the kernel at boot

noibrs noibpb spectre_v2=off spec_store_bypass_disable=prctl spec_store_bypass_disable=off nospectre_v1

this seems to be the go to to check that these patches have been applied and enabled
you could use this in reverse to make sure this is disabled.

if there's an actual official documentation page with all these options someone please link it


it's listed here, atleast the command line options, but there needs to be a dedicated page with "here are the security options that will cut your performance in half and here is the config option in the kernel config and the boot parameter to disable it at boot"

This fucker just never gives up; he just constantly posts usenet and mailing list quotes from three decades ago. What a sad, pathetic autist.

I like him

He's better than 99% of the posters here

Nobody asked for your asskissing either. Fuck off, brown-nose nigger.

ADHD Niggers get told

Attached: auschlitz.jpg (720x693, 34.52K)

t. unix weenie

no u

Still better than the autist whose entire purpose in life is to complain about him. You are really obvious, mate.

Oh boy, can't wait for my 11 year old computer to be even fucking slower unless I just go back to Windows XP again. And it will still be more usable than Windows 10 and the BSDs. With this level of competition, I wonder how nothing good is ever made.

You can't break what has always been broken.

And you keep complaining about him. Thanks for that, I'm going to screenshot all of his posts and they will become my wallpaper when I stop being lazy. It will be especially hilarious on my Linux PC, if I can ever get it to work, because Linux is objectively shit and I only use it because the first version of Windows 7 is slightly outdated and also breaks occasionally. He will never give up, because of balls of steel, or severe autism that I can relate to, or both.




Thx for making a compilation of his posts


I thought the impact of those mitigations was mostly in specific workloads and not largely typical desktop tasks. Benchmarks are welcome though.

Idk if that's true but it might definitely be it.

Just try updating Windows Vista, Windows 7, 8.1, Server 2008R2 or Server 2012R2 with the spectre hotfix, and if you're running it on a toaster or a vm, watch as the system turns noticeably more sluggish and unresponsive after reboot.

What do you mean by "first version" of Windows 7? Are you talking about Pre-SP1 Windows 7?

GPL is revocable, and Unix-Hater is correct in his opinions.

Nope, even RedHat half-heartedly admits it:

> opensource.com/article/19/2/cla-problems

Notice how they hand-wave it.

"Guy backed down, don't look behind this curtain"

You can revoke. Their only power against you is getting you fired/blackballed. If you do not give a shit about their "industry" you C A N fuck them completely. You have revoke and sue, and you really want to do so in a bloc with like minded, once you get the ball rolling, it's the doom of the project.

Why do you shill?
The text says the opposite of what you proclaim.
Why do you shill and does your family know about it?

KYS, Mikee.

Nope, it's tacit approval of my stance. That is why they then say "oh but we've delt with this extra-legally, no worries".

The fact is other lawyers do caution that without a copyright transfer, the copyright owner can revoke the license at will.

Read it again. That is: even RedHat agrees that this is a legal possibility, but in it's press release hand waves it away with some "we'll we'll just get the guy fired" bullshit. Yes you lay people cannot separate the legal language from the bullshit language, but we lawyers can.

> opensource.com/article/19/2/cla-problems

Let's go through it line by line

Why? I'm right you know. And more and more people are realizing that.

more (((backdoors)))
trannies/sjw shit is how deep state gets inside

this compilation should be made the background of Zig Forums

this is propaganda by intel. there are measurable performance drops across the board. there's a wide variety of benchmarks available for these patches already.
20% I/O performance drop
17% compile performance drop
23% socket performance drop
30-78% network performance drop
9% across the board anything using glibc performance drop
4% gimp performance drop
22% memcached performance drop
22% nginx performance drop
19% apache performance drop

older processors which Zig Forums is prone to use in an effort to escape the botnet are prone to get fucked much harder according to the benchmarks.

He didn't test core2-duo, i'd love to see how hard that get's fucked.

i would bet anything these vulnerabilities were included intentionally as a planned obsolesce thing from intel and glowniggers in general to be used once the majority of exploits for the previous version of the botnet were used up, discovered and mitigated, so they could force everyone to upgrade to botnet 2.0 with a whole new set of fresh 0-days.

You faggots don't compile your own kernel? It's fucking easy to configure if you know what hardware you have and when you throw all the shit out you don't need it compiles fast too and you can optimize a little. There are a bunch of switches for spectre/meltdown and also other stuff you can disable that doesn't apply to your computer and will bring in a bit of performance. It's all well laid out and documented in the kernel configuration menu.

I swear to god, Zig Forums is full of zoomer larpers these days.

abloo-bloo I'm literally helpless if I can't get the kernel configuration switches off google and reddit. lmao

literally juts installed 5.0

I recently learned KASLR does literally nothing and is still exploitable. I also learned that kernel devs are retards that won't implement security featues. For example grsecurity's specter and meltdown mitigations come at no cost to performance. But the linux kernel's mitigations have huge performance impacts. (((Why))) is that?

that would be great if that was, but it isn't.
tell me where all the spectre and meltdown patch documentation is and how I can easily locate it in the kernel config

tell me exactly where in the kernel config spectre mitigations are without resorting to a search engine.

where does it say this is going to result in a 30% performance penalty? Where does it even suggest if this should be enabled or disabled? Where is the documentation?

to be fair there is a slightly more elaborate two sentence explanation on the config option

how much slower?
there's not even a suggestion "enable if unsure" etc that's common on some of these options. As far as I can tell, this two sentence explanation of retpoline is the extent of linux kernel documentation regarding retpoline.

not only that, it isn't listed under security, it's listed under processor type and features, despite not having anything to do with enabling any actual processor features for specific types.

There was a nice little blurb here

turns out there's also:
l1tf meltdown spec_store_bypass spectre_v1 spectre_v2
cat on any of these in >/sys/devices/system/cpu/vulnerabilities/ gives a little blurb about what is mitigating these or not,

the only thing I can find is this l1tf documentation which only covers l1tf. what about other 4, meltdown spec_store_bypass spectre_v1 spectre_v2?? how do I know what possibilities there are for what this can spit out?

the point remains that the kernel documentation is scattered all over the fucking place, and 9/10 significant research is required to figure out what is what. i'll bet after the research the only documentation I'll find on this shit is some random lkml from a patch somewhere, and that'll have to do it because the only alternative is what some faggot said on reddit somewhere.

this is why redhat is so popular and destroying linux in the process. no company is going to want to deal with this shit, they are much happier to pay $5000/mo and pick up a phone and get an explanation that redhat has dealt with it in their last kernel update and don't worry about it.

(((Why))) is that?
the same reason linus sat on it for a fucking year while intel did nothing and still scrambled at the last minute when the (((embargo))) expired.

These embargo's are ultimate jewry. They exist only to protect the financial interests of the jew.

Linux kernel is dead, Microsoft will be taking over in 2021

And India will become a nuclear superpower by 2020

And Hillary will become president in 2020

And the UK will repeal article 50 and remain the EU in 2020

They are retarded faggots who oppose men having child brides, what do you expect. Good people want what's best for their fellow man and what's worst for their not-fellow woman-enemy.

Linixarians used to be like this, 15 years ago, then they let in the women. Now they do NOT let in security.

>For example grsecurity's specter and meltdown mitigations come at no cost to performance. But the linux kernel's mitigations have huge performance impacts. (((Why))) is that?

I pointed this out awhile ago, I was told I was lying and PROOFS!

It's because Spengler and PaX team know how the underlying hardware works. Linus _DOES NOT_. He is a stupid fuck that married a dog ugly woman.

No response ofcourse.

Line by line again. Redhat does not refute that the GPL is revocable, tacitly shows agreement.

Intel, MS, Google, and IBM own Linux. There is no "community."

if you actually know how to program then you too can get your code in linux. its just that most here do not know so they just post that kind of shit instead of actually doing something useful.

[citation needed]
show me the last commit to the linux kernel that wasn't by a (((big tech))) employee or someone otherwise officially employed to work on linux.

Linux supports highly obscure devices simply because there are programmers willing to maintain drivers for them. Anybody can write anything as long as Linus approves of how your specific system integrates into Linux. Linus rejected the systemd's team for kdbus not because he hates systemd (he doesn't) but because he disapproved the way the kdbus system integrated into Linux.

Linus is a very practical guy, he doesn't really have any convictions either way, he just cares about the quality of the kernel.


Do you want your Intel machine to support Spectre based attacks? It seems like that you'd rather prefer for Linux to support spectre attacks over proper security.

which spectre mitigations does 5.0 have that 4.X doesn't?
I thought they were all backported.

The reason why there is a spectre exploit in Intel (and AMD) is because Intel were making use of parallel processing techniques to increase the performance of the chips. The flaw with these performance techniques means that people are able exploit the chip and control it. The Linux software fix to prevent the spectre exploit from working is what caused the performance drop. If you're not allowed to use the functions that support high performance, you're going to lose the performance benefits of that feature.