Linux 4.9 Is Showing A Performance Boost On More Systems

[karolherbst]

aford173



Ah my apologies, somehow didn't see the word "ARM" (I guess since I'm used to it being capitalized). Anyhow, would have to see what ARM hardware I have around that's fast that would work for benchmarking and also work on the mainline kernel. I don't think my Jetson TX1 yet works on a mainline kernel and using like a RPi would be too slow until some official packages come out :/

well the kernel side is fine though. Problems are on the X side, because the tegra chip does 2d stuff, but the 3d engine the rendering. So in the end you need prime offloading in the modesetting DDX for glamor. Fun times.

Alex has some patches for this though, but can't find the links for this yet...

[karolherbst]

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

[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.

[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.

[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.

[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

[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.

[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.

[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.

[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.