RHEL9 Raises Base Target For x86_64 CPUs Plus Possible Optimized Libraries With glibc-hwcaps

[phoronix]

Phoronix: RHEL9 Raises Base Target For x86_64 CPUs Plus Possible Optimized Libraries With glibc-hwcaps

As we reported almost one year ago, Red Hat was looking at likely dropping older x86_64 CPU support from Red Hat Enterprise Linux 9 and we now have a better idea of their plans in catering RHEL9 better to modern processors...

http://www.phoronix.com/scan.php?page=news_item&px=RHEL-9-x86-64-v2-Plans

[ms178]

x86-64-v3 in fact requires not only AVX but also AVX2 which would set Haswell as the minimum on Intel and Excavator on AMD. By the way, the once-discussed feature level with AVX1 only was dropped. As there was a huge outcry from AVX2 as a new baseline a year ago when Red Hat first discussed their plans to raise CPU requirements, I understand that they took the more conservative approach first. Although it is just a matter of time to move it further along. Thanks for defining these new feature levels, it helps to move things forward and I hope it will even translate into the Windows world.

[ermo]

I keep a couple of PhenomII CPUs around, one of which is running as my home server because it and its motherboard supports ECC and currently has its RAM slots populated with ECC DIMMs.

I can't really argue with the approach that RH has taken here, as it plainly makes sense to move on from 10+ year old hardware and thus be able to take advantage of newer instruction sets and the extra energy efficiency they allow in certain scenarios.

I can, however, take issue with intel's product segmentation strategy that chops up support for various functionality (e.g. VT-x and VT-d) and instruction set extensions (AVX, SSE4.x); that approach is just asinine and is actively keeping me from supporting intel with my wallet. Unless and until intel stops this skullduggery, they're not an option to me.

AMD's approach is much simpler from a marketing perspective; if I buy an AMD processor, I don't have to worry whether this or that instruction set extension or functionality is supported because I haven't noticed AMD actively remove functionality for artificial product segmentation reasons within a single generation of chips. And with the Zen generation of chips, AMD has even become a viable alternative from not just a value standpoint, but also from a performance and capability standpoint. That said, AMD *is* coming from behind, which might be part of the reason that they simply haven't bothered "optimising" their product segmentation strategy beyond their current approach of dividing their product lines into easily digestible value/performance price tiers.

Your move, intel.

[ms178]

I can, however, take issue with intel's product segmentation strategy that chops up support for various functionality (e.g. VT-x and VT-d) and instruction set extensions (AVX, SSE4.x); that approach is just asinine and is actively keeping me from supporting intel with my wallet. Unless and until intel stops this skullduggery, they're not an option to me.

AMD's approach is much simpler from a marketing perspective; if I buy an AMD processor, I don't have to worry whether this or that instruction set extension or functionality is supported because I haven't noticed AMD actively remove functionality for artificial product segmentation reasons within a single generation of chips. And with the Zen generation of chips, AMD has even become a viable alternative from not just a value standpoint, but also from a performance and capability standpoint. That said, AMD *is* coming from behind, which might be part of the reason that they simply haven't bothered "optimising" their product segmentation strategy beyond their current approach of dividing their product lines into easily digestible value/performance price tiers.

Your move, intel.

This move is the first in a long time where it becomes clear that ISA support matters, and that it matters a lot. Tons of reviewers did get that wrong at that time when recommending these cheap Pentium G CPUs, suggesting that AVX-support wouldn't matter that much, and while this was true at that point in time, it turned out to be of more significance now. Intel's market segmentation on the ISA-level hurts them now, but more so users who were either not paying attention or were picking a CPU without taking ISA support into account as there were AMD alternatives with these features at that time in this price range, and these AMD users are now better off with OS support.

As AMD usually lacks behind Intel in ISA-support, I'd say not having AVX-512 support now could hurt AMD users down the road tomorrow. I would have thought that they would bring it to AM4 with Zen 3, but they did not. We know now what that means for Zen 3 users as Zen 4 is rumored to get AVX-512 support, that is the next CPU to get for better long-term value....

[dbkblk]

AMD's approach is much simpler from a marketing perspective; if I buy an AMD processor, I don't have to worry whether this or that instruction set extension or functionality is supported because I haven't noticed AMD actively remove functionality for artificial product segmentation reasons within a single generation of chips.

Maybe it's out of topic, but I bought a laptop with ATI Radeon HD2000Mobility back in the days (it was already part of AMD), and they officially removed support for it a year and half later (the laptop was shiny brand new). I won't be that confident about market practices.

[Alliancemd]

I hope other distros follow-up since that would bring up a little bit the performance of Linux in general. x86_64-v2 is very very old hardware, so it's pretty safe for newest distro versions.

[OneTimeShot]

It's a real omission that ELF can't support multiple binary architectures in a single file... There must be lots of cases where it would be useful to have processor specific optimisations in an executable/shared object without having to ship an entirely separate directory of files.

[satadru]

It's a real omission that ELF can't support multiple binary architectures in a single file... There must be lots of cases where it would be useful to have processor specific optimisations in an executable/shared object without having to ship an entirely separate directory of files.

https://en.wikipedia.org/wiki/Fat_binary#FatELF:_Universal_binaries_for_Linux

[CommunityMember]

I hope other distros follow-up since that would bring up a little bit the performance of Linux in general. x86_64-v2 is very very old hardware, so it's pretty safe for newest distro versions.

For enterprise distros such as RHEL, targeted towards the (large) enterprises, the enterprises still using 10+ year old hardware should seriously consider replacing it for space and power reasons alone. And for those that need to operate 15 year old servers, they always have the previous release of EL. Enterprises will vary, but lifecycle replacement is typically around 3-4 years due to the financials alone (newer hardware is more capable, smaller footprint, more power efficient, lower maintenance costs, along with the depreciation write-offs), so it seems likely that the vast majority of RH customers will see no impact on their operations to require newer hardware.

[skeevy420]

My workstation is literally the cutoff line