Linux 3.17 To Linux 4.16 Kernel Benchmarks On Intel Gulftown & Haswell Hardware

[Michael]

Why NO AMD CPU?

I retired all my old FX/Opteron boxes from the racks.... Zen won't work nicely going back to kernels that old.

[HoermI]

I retired all my old FX/Opteron boxes from the racks.... Zen won't work nicely going back to kernels that old.

Would be interesting to see a piledriver based chip do these benchmarks and see if there are any relative differences in the slowdowns in the newer kernels.

[sa666666]

It would still be nice to see Ryzen in at least part of the graph where it can be tested (ie, back to the first kernel that supported it). That way, we could see if the mitigations are slowing down AMD systems, or if it's the kernel itself has gotten slower over time. And also, how Ryzen compares to Intel wrt mitigations.

[Michael]

It would still be nice to see Ryzen in at least part of the graph where it can be tested (ie, back to the first kernel that supported it). That way, we could see if the mitigations are slowing down AMD systems, or if it's the kernel itself has gotten slower over time. And also, how Ryzen compares to Intel wrt mitigations.

Yes I will have some fresh threadripper kernel tests in next day or two, was just explaining why there weren't any AMD results in a 3.17 to 4.16 article.

[Vistaus]

You must not have the updated microcode yet (not sure if intel will even be releasing updates for Westmere tho). The updated microcode just released last week from intel exposes the hooks that allow for higher performance mitigation (aka Restricted Speculation). Your Westmere probably has speculation disabled entirely in 4.15+ due to the buggy microcode.

Boot 4.15 and do a 'dmesg | grep -i spectre' to know for sure. My Ivy Bridge Xeon with latest microcode and kernel 4.15.10 shows this:

$ dmesg | grep -i spectre
[ 0.014792] Spectre V2 : Mitigation: Full generic retpoline
[ 0.014793] Spectre V2 : Spectre v2 mitigation: Enabling Indirect Branch Prediction Barrier
[ 0.014793] Spectre V2 : Enabling Restricted Speculation for firmware calls

As for RHEL, their kernel is not vanilla, not even close to it. Red Hat back-ports massive amounts of stuff from the newer kernels to their baseline.

Last week? You mean two weeks ago? 'Cause the latest available microcode package was released on 2018-3-12: https://downloadcenter.intel.com/dow...code-Data-File

Or am I missing something?

[pcxmac]

I retired all my old FX/Opteron boxes from the racks.... Zen won't work nicely going back to kernels that old.

you should try gentoo, just rebuild the older kernels with the newer compilers. A lot of the binary repos are trash in this respect. Especially if you are security conscious, and you want to make sure your code is compiled in the right way.

ps, if you do git repo w/ gentoo, you can roll back

[Michael]

you should try gentoo, just rebuild the older kernels with the newer compilers. A lot of the binary repos are trash in this respect. Especially if you are security conscious, and you want to make sure your code is compiled in the right way.

Simply rebuilding the older kernels with the newer compilers won't work for chipset support, etc for Zen platforms missing on the much older kernels.

[MaxToTheMax]

Can someone explain what the deal is with the pgbench results? Looks like the 990X is outperforming the 5960X by a huge margin.

[gregzeng]

Michael The vertical graph axis should always start at 0, otherwise the changes can be exaggerated to the point of being misleading.

Starting from "zero" would show no difference, graphically visible to the naked eye. More meaningful might be the the percentage changes, at least for the highest & lowest points, compared to the base line? If the difference is just "0.1 %", the difference might be enough to explain by chance alone IMO.

[gregzeng]

"SYSTEMS TOTAL BOOT TIME" (web_page_2). Two seconds difference between the slowest & the fastest Linux kernels. Some of us are interested if SYSTEMD also is better or worse at BOOT TIMES without the Linux "speedup" feature. On systems with low powered CPU, slow I-O, etc, this could be very significant. Especially systems that need fast boot-timings.

Perhaps without systemd, the differences in boot time should be different. But faster or slower? For which kernel versions. In these cases, the later Linux kernels may not be recommended, unless the very specific "improvements" justify the movement to an later Linux kernel.