Recent searches
Search options
"In #RHEL 9, we upgraded the ISA baseline to the x86-64-v2 microarchitecture level. For RHEL 10, we are exploring whether we can go a step further, to the x86-64-v3 level."
From Florian Weimer: https://developers.redhat.com/articles/2024/01/02/exploring-x86-64-v3-red-hat-enterprise-linux-10
@kernellogger If they end up doing this, I guess it means effectively giving up on hwcap as the mechanism and going back to just requiring a particular set of ISA extensions. Because of Intel's marketing, this not just locks out old microarchitectures but also low-end Celeron and Pentium Gold processors still sold today (anything older than the latest Pentium Gold 7xxx/8xxx). It's probably fine for RHEL as one would not put it on a $400 laptop, but some Centos users will care.
@kernellogger For arm64, the hwcaps support is somewhat more important still, as you need that for things like SVE2 (ARMv9) or LSE atomics (ARMv8.1). If RHEL ends up no longer using hwcaps for library loading on any architecture, that would mean either dropping support for common Cortex-A72 (ARMv8.0) machines or running slower than necessary on all newer ones.
@kernellogger On the other hand, I would personally welcome kernel configuration options that allow building for a somewhat more modern CPU. Both x86-64 and arm64 currently always support everything back to the earliest K8/Pentium4 or X-Gene/Cortex-A57/A53 CPUs. Having a newer (optional) baseline would turn some important runtime decisions into compile-time optimizations.
@arnd @kernellogger For arm64 I would love to see v8.2 to be a new minimum. Atomics being default, not option.
But so many v8.0 systems out there still.
thx for your insights, much appreciated.
re "locks out […] low-end Celeron and Pentium Gold processors": had similar thoughts when reading that post.
re "kernel config options" yeah, it's kinda astounding that nobody yet submitted infra for such kernel config options
@oleksandr @kernellogger @vbabka your small patch looks like it could address an actual problem: as I just noticed, there is no -march= argument for normal builds on either x86_64 or arm64, so the kernel ends up being built for whatever was set as the default was at gcc configure time using --with-cpu=.
On the one hand, that means any distro build will already get a kernel optimized for whatever CPU is targeted by userspace, but on the other hand it does make kernel builds less reproducible.
@kernellogger @vbabka @arnd so, CONFIG_GENERIC_CPU should correspond to -march=x86-64 -mtune=generic, not only -mtune=generic?