Linux 5.0 Kernel Performance Is Sliding In The Wrong Direction

[microcode]

Let's hold out judgement, but maybe we'll look back to the day Linus went soft as the inflection point for kernel performance.

Just a hypothesis for now, waiting for data. ;- )

[Azrael5]

a disaster. Linus Trovalds needs to be maintained.

[moilami]

This is because Linux CoC

[Guest]

Don't care for the benchmarks. I just came to say that I dislike the clickbaity title.

[Wojcian]

It seems it's better than I thought:

https://openbenchmarking.org/result/1902237-KH-TEST1517319

[audir8]

I don't think the Ubuntu PPA is a great candidate for this type of kernel-specific testing. A stock Ubuntu config from the PPA isn't necessarily going to be defconfig, which is what we want. I don't know if building a defconfig kernel is possible from the deb-src packages or not (It's not, there aren't any src packages that I could find). I think you have build each kernel on your own. Not too hard at all.. make defconfig deb-pkg

These config patches in the PPA are probably not defconfig:
https://kernel.ubuntu.com/~kernel-pp....0-10.11.patch
https://kernel.ubuntu.com/~kernel-pp...20.0-2.3.patch

[entropy]

Is there a good reason to use the geometric mean for the comparison between different kernels?

Lacking robustness in estimators always means that a few outliers affect the result significantly
in a misleading way.

To me it looks like sockperf and postgres (for 5.0 only in this case) are signficantly slower.
In all other cases 5.0 is only marginally slower - but a trend is obvious, I agree.

Yet, the "Geometric Mean Of All Test Results" that might give the impression like 5.0 i
more than 10 % slower on average is completely misleading and not helpful imho.

[Guest]

While I'd love to say that the ship is sinking, the golden era of Linux is over, that Torvalds killed the project by adding the CoC, and that we should all move to DragonFlyBSD's kernel, I think it's too early to say. Right now it doesn't really look like post-CoC kernels have a trend to degrade performance, and there's a possibility that this build of 5.0 was misconfigured, or that some bad commit went through and wasn't reverted yet. This isn't a proper 5.0 release, so the best thing to do is to wait and benchmark once more later.

[r08z]

These are the kinds of benchmarks we love to see. The kernel is the heart of the OS and it's performance matters most before glibc. Proprietary binary applications like Valve games and others rely on these two components. I wish there would be more benchmarks like these comparing long-term kernels to new ones more often.

[PF-SYS]

Never use 1000hz timer. Nor 10ms filter in sched.c, which basically reduces it to below 100hz in practise..

Hz is there to optimize inner loop. "GNU" indeed over time, seems to be a decisive factor, in the cause of this, and causes "bloat over time" aswell, and reduced performance
All the criticisms of GNU is deserved. And a new symbol Moo will not solve it either. Nor "kind communication guidelines". It needs complete philosophical coherence.

And the kind of regressive thinkings on economy in that environment will ultimately halt it completely.

However Apple bases themselves on BSD and makes a living. And Microsoft have now incorporated Linux elements in their system.
The best way in between - A Pay Fair OS out of FreeBSD.

Also click About here: https://www.youtube.com/channel/UCR3...S5A702wo4bol_Q