RHEL9 Likely To Drop Older x86_64 CPUs, Fedora Can Better Prepare With "Enterprise Linux Next"

[archsway]

I don't think it has yet been decided on the specific feature requirements, but remember that RHEL is targeted towards supporting enterprise customers and solutions, which typically means DCs, and that means recent server class hardware (anyone who has actually done the TCO math for a DC can show that after a few generations of hardware it is cheaper to replace the hardware than keep it running), and not consumer devices. Sure, it is nice to be able to support someone's low end laptop, but RH makes their money from paying enterprises, which deploy serious iron, for the most part. How many people here can say they are actually paying full RH support prices for their laptops or seven year old servers? Those people can certainly make the case to RH that their loss of revenue may be important, but it is unlikely to be significant enough to change anyone's mind as to where to invest their resources (QA is extremely expensive for these enterprise vendors).

What about people who use RHEL on their personal machines to be consistent with the "serious iron" they deal with at work?

You know, the ones who would switch all the serious iron to SUSE or Ubuntu rather than "upgrade" their own laptop (see chithanh's comment)?

[pegasus]

Guys,
By the time rhel9 becomes a thing, gcc will fully support "fat" binaries with multiple optimized versions of the same function and switching between them at runtime.
So I see no issue whatsoever to build whole distros with binaries that include all possible optimizations, from generic to avx512 and everything inbetween.

[Space Heater]

By the time rhel9 becomes a thing, gcc will fully support "fat" binaries with multiple optimized versions of the same function and switching between them at runtime.

Where can we follow the progress of this feature in gcc? Have patches been submitted for review?

[szymon_g]

You need a newer kernel (cannot remember the exact version, but CentOS 7 doesn't have it and Ubuntu 18.04 has).

uname -a
Linux ubugrat 5.4.0-18-generic #22-Ubuntu SMP Sat Mar 7 18:13:06 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

vendor_id : AuthenticAMD
cpu family : 21
model : 101
model name : AMD PRO A12-9800B R7, 12 COMPUTE CORES 4C+8G
stepping : 1
microcode : 0x600611a
cpu MHz : 1794.015
cache size : 1024 KB
physical idprocessor : 0
siblings : 4
core id : 3
cpu cores : 2
apicid : 19
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb bpext ptsc mwaitx cpb hw_pstate ssbd ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic vgif overflow_recov
bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips : 5389.86
TLB size : 1536 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro acc_power [13]

[sfx2000]

You need a newer kernel (cannot remember the exact version, but CentOS 7 doesn't have it and Ubuntu 18.04 has).

Seems that Fedora is being short-sighted - this is Pentium N3700 - it's a 14nm processor, so not that old, and on the higher end of the Airmont family of chips.

Linux blue 5.3.0-42-generic #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 76
model name : Intel(R) Pentium(R) CPU N3700 @ 1.60GHz
stepping : 3
microcode : 0x368
cpu MHz : 720.085
cache size : 1024 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat md_clear
bugs : cpu_meltdown spectre_v1 spectre_v2 mds msbds_only
bogomips : 3200.00
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

[zxy_thf]

Seems that Fedora is being short-sighted - this is Pentium N3700 - it's a 14nm processor, so not that old, and on the higher end of the Airmont family of chips.

Actually they aren't.
Thanks to Intel's market segmentation, we will be able to buy new Pentiums/Celerons/Atoms w/o AVX2 support for the next decade(s).
So there will never be an era that all new chips are supporting AVX2.

[Marc Driftmeyer]

Enterprises are slow to upgrade processors. The SSE4.1 makes sense. AVX when most tools were never written for it to push vendors to buy new hardware will see more vendors moving away from RHEL, not towards it.

[NateHubbard]

Came here expecting people to be defending their ancient hardware (like usual with these articles) and wasn't let down.

As others have said, RHEL is for servers anyway, not outdated and/or low end consumer machines.

[TemplarGR]

Much like the first version of SSE (back when it was still called ISSE), the first version of AVX isn't all that useful for accelerating generic software. Requiring AVX over e.g. SSE4.1 would just exclude a number of CPUs with no real benefit.

I don't think they are going to cut off older architectures in order to benefit from modern SIMD instructions. Well, obviously they will, but i think their primary target is using the instruction set as a cutoff point for old cpus. I was promoting the first AVX mainly on that grounds, since i think cpus first released during 2011 would be a nice balanced minimum for a distro released in 2023. 12 years is not too old for a baseline, and does not cutoff useful hardware either.

[mlau]

I don't think they are going to cut off older architectures in order to benefit from modern SIMD instructions. Well, obviously they will, but i think their primary target is using the instruction set as a cutoff point for old cpus. I was promoting the first AVX mainly on that grounds, since i think cpus first released during 2011 would be a nice balanced minimum for a distro released in 2023. 12 years is not too old for a baseline, and does not cutoff useful hardware either.

AVX2 is a better cut-off point, as it implies a few other extensions as well: BMI1/2, FMA + F16C, MOVBE, ...