Intel Continues With More Big-Time Optimizations To The Linux Kernel

[phoronix]

Phoronix: Intel Continues With More Big-Time Optimizations To The Linux Kernel

I love Linux kernel patches that mention "massively", use exclamation points when talking about performance, and/or simply mention big speed-ups. Quite often such patches come out of Intel and last week they sent out another great performance optimization patch series to improve additional low-level bits of the kernel...

https://www.phoronix.com/news/Intel-rcuref-Linux-Speed-Up

[kozman]

Dang!!!!! <---(Adds own exclamation marks) Again, how many bottleneck investigations are still waiting in the wings to find these kind of perf improving gems? Good job to the devs for find and fixing this one. So what is the chance of this getting back-ported to older / LTS kernels?

[microcode]

I love that feeling when I find something like this too, and there are actual real applications that this benefits as well, not just his synthetic benchmark.

[kozman]

I love that feeling when I find something like this too, and there are actual real applications that this benefits as well, not just his synthetic benchmark.

Exactly. You'll have a lot of devs and admins now making the case in certain datacenter arenas and other network heavy setups kind of saying "see, I told you so" instead of pouring tons of $$ into hardware upgrades to fix the issue when it's just an oversight in code being revealed by a bottle neck. Do tools exist to hunt for these kinds of bottlenecks or is it just a dev staring at something and trying to figure out why something should be going way faster than it is but isn't?

[kozman]

Reminds me also of the BFQ story: https://www.phoronix.com/news/Linux-6.3-Block-Changes

A simple tweak that just required some effort at realizing the potential gains. All these little nuggets are just waiting for someone to come along and put in some sweat equity and all the Linux community gets a boost. So cool. I have mad respect for the code ninjas who are able to figure this complex stuff out. Part of why I tried to get into programming years ago but just never had a good teacher or be pointed in the right direction to learn on my own.

[sinepgib]

Exactly. You'll have a lot of devs and admins now making the case in certain datacenter arenas and other network heavy setups kind of saying "see, I told you so" instead of pouring tons of $$ into hardware upgrades to fix the issue when it's just an oversight in code being revealed by a bottle neck. Do tools exist to hunt for these kinds of bottlenecks or is it just a dev staring at something and trying to figure out why something should be going way faster than it is but isn't?

Your comment reminds me about the GTA V load time bug that most Rockstar fans attributed to the "very complex stuff the game engine needs to deal with". It was a O(n^2) JSON tokenization and the thing got like 10x faster or something
Nothing kills performance like assuming it can't be improved.

[sinepgib]

So what is the chance of this getting back-ported to older / LTS kernels?

I think nobody knows until it happens, but my money is in that not happening. The role of LTS is typically to try to port the least possible changes to fix serious (mostly security) bugs so you can have some confidence that nothing will start to misbehave due to the fast paced changes of mainline.

[kozman]

Your comment reminds me about the GTA V load time bug that most Rockstar fans attributed to the "very complex stuff the game engine needs to deal with". It was a O(n^2) JSON tokenization and the thing got like 10x faster or something
Nothing kills performance like assuming it can't be improved.

Exactly right. Any good IT person / coder knows it can be improved. It just requires the hard work be put it. Only fools and IT dinosaurs adhere to the broken tenet (as applied to IT in general) that "If it ain't broke, don't fix it." It is broke. Us mere mortals are just not smart enough to know where or how and as continually evidenced by *really* smart hackers and super smart code ninjas.

[kozman]

I think nobody knows until it happens, but my money is in that not happening. The role of LTS is typically to try to port the least possible changes to fix serious (mostly security) bugs so you can have some confidence that nothing will start to misbehave due to the fast paced changes of mainline.

It's a bummer if it weren't backported but I get why LTS is managed in the way it is. This change hasn't been vetted long enough so who knows if it has unforeseen negative impacts after being in production for some time. Of course, nothing is stopping a distro from picking up the fix or if Linus et al give their blessing as well.

Was the underlying code that got fixed existing for some time or is this new to kernel 6.2 and higher? I don't know the originating chronology of it tbh.

[sinepgib]

Exactly right. Any good IT person / coder knows it can be improved. It just requires the hard work be put it. Only fools and IT dinosaurs adhere to the broken tenet (as applied to IT in general) that "If it ain't broke, don't fix it." It is broke. Us mere mortals are just not smart enough to know where or how and as continually evidenced by *really* smart hackers and super smart code ninjas.

Eh, "if it ain't broke, don't fix it" is valid in most situations. But 5 minutes load times are broken unless you can prove the contrary. There's only so many coffees I can drink to wait for my computer to think.
I agree that it's often poorly applied.

It's a bummer if it weren't backported but I get why LTS is managed in the way it is. This change hasn't been vetted long enough so who knows if it has unforeseen negative impacts after being in production for some time. Of course, nothing is stopping a distro from picking up the fix or if Linus et al give their blessing as well.

Was the underlying code that got fixed existing for some time or is this new to kernel 6.2 and higher? I don't know the originating chronology of it tbh.

Yes, distros can and often backport performance fixes. At least I know RHEL did backport some for the AF_PACKET sockets several releases back at the time.
GKH is the one maintaining LTS kernels, so most likely it's up to him for the official LTS. I have no idea when the previous code was introduced. I would assume it is not new.