Red Hat Evaluating x86-64-v3 Requirement For RHEL 10

[phoronix]

Phoronix: Red Hat Evaluating x86-64-v3 Requirement For RHEL 10

Not only is Canonical exploring Ubuntu x86-64-v3 builds for targeting Intel and AMD processors with AVX/AVX2 support, but Red Hat has publicly confirmed now they are exploring a possible x86-64-v3 requirement for next year's Red Hat Enterprise Linux 10...

https://www.phoronix.com/news/RedHat-RHEL10-x86-64-v3-Explore

[Kjell]

CachyOS has been offering v2,v3,v4 + LTO packages for a long time

Wish they would team up with Artix Linux to provide a SystemD-free solution (Dinit) with optimized packages

[ms178]

coder will be mad for Red Hat not caring about Elkhart Lake or similar AVX2-less CPUs any longer.

[coder]

coder will be mad for Red Hat not caring about Elkhart Lake or similar AVX2-less CPUs any longer.

I think it's an unnecessary, self-inflicted wound, but at least their logic of wanting to reduce the support burden of ISVs is well-formed. I wonder just how many ISVs have been raising this issue. I'd be surprised if it's more than a handful.

Perhaps Redhat is just playing up that argument, since it's more robust than their own internal motives for dropping v2 and earlier.

[skeevy420]

CachyOS has been offering v2,v3,v4 + LTO packages for a long time

Wish they would team up with Artix Linux to provide a SystemD-free solution (Dinit) with optimized packages

Speaking from personal experience, if you write it as SystemD then no one will take your criticisms of it seriously. Spelling it like that makes you come off as either a hater or a moron because it means you're either intentionally being an asshole or you don't even care enough to see what the correct spelling is.

That's coming from someone that used to spell it that way because it's easier to read and would prefer it to be the project's actual spelling. The moron.

[avis]

I cannot believe anyone uses RHEL with Atoms or such old HW that it doesn't support AVX2, so RHEL may as well go with it.

[Kjell]

Spelling it like that makes you come off as either a hater

No, it's just easier to read.

I see you literally doing advertising about this distro every time here.

I do the same with AMD.
Word of mouth is the best way to promote a good product.

Vote with your wallet and spread positive experiences.

[SofS]

I cannot believe anyone uses RHEL with Atoms or such old HW that it doesn't support AVX2, so RHEL may as well go with it.

On the contrary, certainly there are many office grade computers with Celerons and Pentiums. Particularly those mini and all in one types. Try to check the next time you sit to talk with any manager if you can see what they are using. If they are using RHEL is another matter.

[NSLW]

This is good news in general as most Intel/AMD CPUs of the past decade support x86-64-v3

Someone is overstretching facts here. If x86-64-v3 is AVX2 then according to Wikipedia the first AMD CPU is Excavator from June 2015.
8.5 years is not a decade. Pretty short period for obsoleting still well performing HW.

[debrouxl]

In a way, mandating x86-64-v3 support for a distro supported for 10 years starting around 2025 - whatever "support" means for a mildly large collection of software, most pieces among which are not supported by their respective upstreams beyond 2 or 3 years, but that's an unrelated matter - is a much more lenient requirement than what:
* VMWare will mandate beyond 2027: EOL of ESXi 8.0, which will shoot down official support for Broadwell (2016) and even Skylake (2017) following Intel guidance;
* Microsoft already mandates for Windows 11, IIRC, due to processor virtualization technology speed requirements.

As far as security technologies are concerned: x86-64-v3 doesn't contain SMAP, which was introduced with Broadwell on the Intel side, and Zen on the AMD side. Haswell provides INVPCID and the earlier PCID, but it took AMD all the way to Zen 3 for implementing these ( https://kb.vmware.com/s/article/1003212 ), so it will still be quite a while before PCID+INVPCID support can be mandated. I know, AMD processors are less in need of PCID than Intel processors are, but still. It's odd that SMAP went much earlier into AMD processors than the older PCID+INVPCID.