Linux 4.9 Is Showing A Performance Boost On More Systems

[Luke]

It's not that bad with modern CPUs. A kernel build on a fast CPU is now ~1min, and even a cheap Skylake Celeron can build a kernel in a few minutes. Automated bisecting makes the compile time even less relevant - it's trivial to "git bisect run" with a test script that compiles, pushes to and reboots the test hardware then polls for the test result.

What KIND of kernel build? A bare kernel or one with all the modules? I build my own kernels complete with full module support, using "make oldconfig" with the configuration files found in /boot from Ubuntu PPA kernels. They take over an hour on an AMD FX 8120, a CPU which is effectively optimized for my video editing loads. I now build my own kernels and cipher stack due to an article here about a possible attack against Debian's package signing system that would permit an MITM attacker to replace prebuilt binaries with their own built from modified source.

[charlie]

...it's trivial to "git bisect run" with a test script that compiles, pushes to and reboots the test hardware then polls for the test result.

Then do it. We are expecting your results within 5 minutes of this post.

[chrisb]

I do hope you have premium membership if you are asking Michael to do a kernel bisect. Bisecting kernels, like bisecting anything else, requires rebuilding for each commit in the range tested until the commit in question is found. This is hard enough to do with GTK3 (which I have done), which builds in about 8 minutes on my systems. A complete linux kernel with a full set of modules as used on a desktop distro can take well over an hour to build, multiplied by the number of commits being tested. Even fully automated that's a lot of CPU time and power, and the results still have to be evaluated by installing and booting that kernel on something, then running tests on that machine.

It's not that bad with modern CPUs. A kernel build on a fast CPU is now ~1min, and even a cheap Skylake Celeron can build a kernel in a few minutes. Automated bisecting makes the compile time even less relevant - it's trivial to "git bisect run" with a test script that compiles, pushes to and reboots the test hardware then polls for the test result.

[chepati]

I already saw roughly a 20% improvement (reduction) in gcc-6.2.0 compile times going from 4.7.6 to 4.8.1. I would be majorly impressed if 4.9 improves on the already much improved 4.8.

[Michael]

I do hope you have premium membership if you are asking Michael to do a kernel bisect. Bisecting kernels, like bisecting anything else, requires rebuilding for each commit in the range tested until the commit in question is found. This is hard enough to do with GTK3 (which I have done), which builds in about 8 minutes on my systems. A complete linux kernel with a full set of modules as used on a desktop distro can take well over an hour to build, multiplied by the number of commits being tested. Even fully automated that's a lot of CPU time and power, and the results still have to be evaluated by installing and booting that kernel on something, then running tests on that machine.

PTS already has support for fully-automating most of it (well, nearly all but matter of false positives and such) but yeah main thing is the time factor involved with heavily using my most frequently used test systems.

[sheldonl]

I do hope you have premium membership if you are asking Michael to do a kernel bisect. Bisecting kernels, like bisecting anything else, requires rebuilding for each commit in the range tested until the commit in question is found. This is hard enough to do with GTK3 (which I have done), which builds in about 8 minutes on my systems. A complete linux kernel with a full set of modules as used on a desktop distro can take well over an hour to build, multiplied by the number of commits being tested. Even fully automated that's a lot of CPU time and power, and the results still have to be evaluated by installing and booting that kernel on something, then running tests on that machine.

I have premium and I'm curious as well. If he gets around to doing a bisect that would be great. If not, then more KDE articles will be appreciated

[Tobu]

Maybe it's the vmalloc-ed stacks? I don't know if the stacks start out smaller now, but if they start at a single page that could be a big win.

[Luke]

This is some really substantial improvements! Could you run a bisection, Michael?

I do hope you have premium membership if you are asking Michael to do a kernel bisect. Bisecting kernels, like bisecting anything else, requires rebuilding for each commit in the range tested until the commit in question is found. This is hard enough to do with GTK3 (which I have done), which builds in about 8 minutes on my systems. A complete linux kernel with a full set of modules as used on a desktop distro can take well over an hour to build, multiplied by the number of commits being tested. Even fully automated that's a lot of CPU time and power, and the results still have to be evaluated by installing and booting that kernel on something, then running tests on that machine.

[edwaleni]

I am seeing small performance improvements on some older hardware with the 4.8 kernel, even on some old dual core Intel Core2 and AMD Turion models. Battery life has improved too. Keep it coming.

[karolherbst]

here they are: https://github.com/Gnurou/xserver/commits/gk20a