One Of The Reasons Why Linux 5.5 Can Be Running Slower

[Random_Jerk]

Wonderful work Michael. Send a Paypal tip your way last night

[dawid.mlyn]

Thanks for your great work Michael. I went premium a few months ago, because of your long-lasting commitment and passion to do a real quality testing and comparisons. Please keep up the good work : ) Best wishes and a Happy New Year!

PS. Quite often I find myself surfing without being logged in to the Forums, so I suppose the statistics are probably biased as many other people may also block trackers / ads / use nano defender etc., while not being logged in and quickly reading the Linux hardware reviews, performance and open-source benchmarks on Phoronix.

[a-zander]

Sadly, most do not, at least for showing support to make future tests possible.

Greater than 50% ad block rates.
Less than 1% being premium subscribers.
Less than 1% tipping.

I am a premium subscriber and it is money well spent for this kind of investigating and reporting. I might be due to renew soon as well.

I do not use an ad blocker, but I do use DuckDuckGo Privacy Essentials and between that and the tracker blockers in Firefox, a number of sites I visit do think that I am using an ad blocker. I wonder if tracker blockers are influencing your block rates.

[caligula]

I haven't measured, but I have not noticed much of a slowdown in kernel compiles on my systems. Do you maybe use a small setting for sysctl vm.dirty_bytes or dirty_ratio? When I do a kernel compile almost all of the output files fit into cache, without needing to do a tmpfs build.

I'm running a new build now just to see. It's an 8 core 1700X with 32 GB RAM and a btrfs disk array. It's a NAS mostly. It does report that PSI for IO has generally 2 processes stuck on IO (full IO stall). So it is getting a slowdown. But I'm not convinced it'd be worth putting the 20 GB of a complete build directory into tmpfs.

My point was, it doesn't need to be significantly faster, only a bit faster. I don't compile kernels that often so not really an expert here. Did a quick test: On my system, NVMe SSD extracts linux 5.4.6.tar.xz in 7.4 seconds, in 7.3 seconds when using tmpfs. A 2.25% speedup. Erasing the kernel tree is 3 times as fast using tmpfs. When building the defconfig kernel, tmpfs build was couple of seconds faster. After this exercise, a fstrim run took few seconds. So, most of the speedup comes from faster filesystem metadata processing. I can't think of any reason not to use tmpfs. I mean it's not like you couldn't store the results of the compilation anywhere. You don't need to intermediate .o files and other compile time artifacts anywhere.

[Steffo]

Nice catch!

[CommunityMember]

Since I can't see any reaction yet on lkml

To quote Linus: "To absolutely nobody's surprise, last week was very quiet indeed". A fair number of the usual suspects were likely off on holiday. I would not be surprised if it may be a bit longer until the author of the commit can review and understand the issues and decide to revert or revise.

[numacross]

I wonder what is the Linux Foundation doing with all those money they get from the companies ???

No need to wonder when it's on their site.

[baka0815]

FireBurn, birdie as in the past, this is Michals bug report.

[ktecho]

Another one just got Premium

Thanks for all the work you do, Michael!

[Danny3]

It's unbelievable how these awful regressions pass unobserved until Michael finds them...
I think it's clear that the Linux kernel who has millions of users has no quality assurance whatsoever.
I wonder what is the Linux Foundation doing with all those money they get from the companies ???

They should be pouring something like 5000 $ / month to Michael for doing this wonderful job of finding this terrible regressions and raising the alarm.
If it weren't for Michael we would have a much lower quality and less performant kernel.