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

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

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

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

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

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

[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)?

[angrypie]

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

Red Hat to a client: "oh, you see, we built our distro to support the latest Zen6 uarch, but none of our developers has the hardware to test it on, so let's see how it works out!"

[zxy_thf]

how did you get that info? just /proc/cpuinfo doesn't show it (i'm mostly interested in the 'bugs' field)

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

[CommunityMember]

Neither AVX nor AVX2 are available on intel celeron or pentium processors.

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

[szymon_g]

Should my 8 year old computer be put in museum?

/proc/cpuinfo:

model name : AMD A6-3670 APU with Radeon(tm) HD Graphics
…
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 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall arat npt lbrv svm_lock nrip_save pausefilter
…
bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2

No avx, no sse4, no sse3, no ssse3 (but it does have sse4a, sse2, sse, 3dnow and mmx).

It doesn't have AMD's two latest vulnerabilities either (this is K10 µarch).

how did you get that info? just /proc/cpuinfo doesn't show it (i'm mostly interested in the 'bugs' field)