9-Way H2'2021 Linux OS Performance Comparison On Intel Xeon Scalable Ice Lake

[phoronix]

Phoronix: 9-Way H2'2021 Linux OS Performance Comparison On Intel Xeon Scalable Ice Lake

While we recently looked at autumn 2021 Linux distributions on Intel Tiger Lake for seeing how these various latest distributions are competing on client platforms, in today's article is a look at how well the latest Linux distributions perform when using the latest-generation Intel Xeon Scalable 3rd Gen "Ice Lake" server hardware with two Xeon Platinum 8380 processors. AlmaLinux, Arch Linux, CentOS Stream, Clear Linux, Debian, Fedora, openSUSE, and Ubuntu were battling it out on this Intel reference server.

https://www.phoronix.com/vr.php?view=30607

[CochainComplex]

Does an AMD fork for ClearLinux exist?
I know you will have benefits by runing CL on AMD too but having a look at the CL build scripts one can clearly see that Intel Arch is always selected when it comes to march flags - for obvious reasons.
Is there a fork out there just building CL with AMD pointing march flags?
Might there be a small improvment towards AMD CPU's?
and could KVM be enabled by default on AMD Systems - afaik it is still not switched on in CL.

[onlyLinuxLuvUBack]

The message is clear that the message is Clear.

[sophisticles]

I know people will get all excited about the supposed advantages that Clear, Alma and CentOS showed but a quick review of the data Michael provides shows that the supposed advantages are simply an illusion:

- AlmaLinux 8.4: Scaling Governor: intel_pstate performance
- Arch Linux: Scaling Governor: intel_cpufreq schedutil
- CentOS Stream: Scaling Governor: intel_pstate performance
- Clear Linux 35100: Scaling Governor: intel_pstate performance
- Debian 11: Scaling Governor: intel_pstate powersave
- Fedora 35 Beta: Scaling Governor: intel_pstate powersave
- Ubuntu 20.04 LTS: Scaling Governor: intel_pstate powersave
- Ubuntu 21.10 Oct1: Scaling Governor: intel_pstate powersave
- openSUSE Tumbleweed: Scaling Governor: intel_pstate powersave

The above probably accounts for the vast majority of the performance differences, with the rest being explained by the following compiler settings:

AlmaLinux 8.4 --with-arch_32=x86-64 --with-tune=generic
Arch Linux
CentOS Stream: -- with-arch_32=x86-64 --with-tune=generic
Clear Linux --with-arch=westmere --with-tune=skylake-avx512
Debian 11 --with-arch-32=i686 --with-tune=generic
Fedora 35 Beta --with-arch_32=i686 with-tune=generic
Ubuntu 20.04 LTS --with-arch-32=i686 --with-tune=generic
Ubuntu 21.10 Oct1 --with-arch-32=i686 --with-tune=generic
openSUSE Tumbleweed --with-arch-32=x86-64 --with-tune=generic

I guarantee that if these distros were retested with their kernels built with --with-arch=westmere --with-tune=skylake-avx512 and their Governor set to performance, that any performance differences would amount to statistical noise.

[yump]

The CPU governors, sure, but I don't think anything in these benchmarks is built for 32-bit, so --with-arch-32 shouldn't make any difference.

Btrfs is probably to blame for SUSE's poor showing in the Postgres benchmarks.

The huge lead for SUSE in Apache concurrency 1000 is difficult to explain.

I wonder if hugepages=always makes any difference over the timescales these benchmarks run? With the default settings, assuming I'm mathing right, it takes khugepaged more than 3 hours to scan all the memory on my machine. Of course, not all of it's allocated, otherwise the system would be completely unusable, but it's still slow enough that it'd probably never get around to a benchmark that finishes in a few minutes. But maybe I'm mistaken that khugepaged is the only way for transparent huge pages to actually come into existence transparently?