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

[kpedersen]

I expect this with something like Arch Linux but for an enterprise distribution? In my experience large companies make use of very aging hardware compared to hobbiests.

[andreano]

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

[carewolf]

So, the fact that Intel still makes processors without AVX still hasn't gotten through to them?

[chithanh]

I think the first AVX version would be a better compromise

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.

Technically Excavator was first in 2015 but IIRC Excavator was not a desktop/server chip but was only found in apus, or wasn't it?

Excavator was found in lots of AMD Carrizo notebooks from that era, and still today AMD sells it in the low-end market (Stoney Ridge). Bristol Ridge was big in AMD OEM desktops in 2016.

People still on FM2+ might be interested in the A8, though.

Problem is that many if not most FM2+ mobos never received a BIOS update for Carrizo. AMD waited so long with releasing that chip that those mobos were considered EOL when it came out.

Requiring AVX2 is therefore a terrible idea. Requiring SSE4 or SSE4.1 would be a better idea.

Not necessarily. The decrease in hardware compatibility will drive away a certain group of users, and the performance gain will attract another group of users. Remember that Fedora serves as staging area for RHEL, so it is all about whether the expected change in demographic is beneficial for that goal.

That being said, I know a number of sysadmins whom you can pry their 7-row keyboard Thinkpads from their dead hands. They would rather switch to another distro than to another laptop.

[angrypie]

Problem is that many if not most FM2+ mobos never received a BIOS update for Carrizo. AMD waited so long with releasing that chip that those mobos were considered EOL when it came out.

The Athlon X4 845 was released earlier, so most if not all motherboards support it. Only the A8 has poor support (I guess only 5 boards support it? What the fuck.)

[zxy_thf]

I think AVX2 is too high of a threshold for now. AMD only made AVX2 cpus after 2017*, and Intel after 2013. Even for a distro released in 2023, i think that's a little too high. I think the first AVX version would be a better compromise, since it goes back a couple of years for both companies (2011 for both Intel and AMD), but is still far more advanced than SS2, (S)SS3 and SSE4.(1,2) cpus.

I would personally make it AVX1 and upwords for version 9 and push it to AVX2 minimum for the next version.

*Technically Excavator was first in 2015 but IIRC Excavator was not a desktop/server chip but was only found in apus, or wasn't it?

Totally agree, but RHEL9 will be released 4 years later, and targeting workstation/server so It will be a lesser problem

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

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

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

[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!"