Hello,

in a wider Linux world a discussion about moving to modern CPU microarchitecture levels (x86-64-v2, x86-64-v3, even x86-64-v4) has been picking up steam. Most major distros are either experimenting with (Arch, Ubuntu), providing support for (openSUSE), planning to support (Fedora) or outright targeting (RHEL) more modern targets. My question is what are Solus' plans? Since Solus 5 is going to be based on SerpentOS, which itself is currently targeting x86-64-v2 and is mulling support for higher levels, is it safe to assume a CPU with v2 compatible instruction set will become the minimum requirement for Solus 5?

  • We've been shipping avx2 libraries for years (known as legacy Glibc HWCaps) built with -march=haswell and installed to /usr/lib64/haswell which we also patched to be compatible with AMD CPUs (zen1 and newer) for opt-in packages. This was based off Clear Linux work that was upstreamed into glibc.

    There was a bit of contention with the Clear Linux work as it exclusively worked on Intel CPUs and not AMD, whilst we patched this behavior in Solus. This in part, lead the creation of the vendor agnostic x86-64-v{2,3,4} microarch levels and the current Glibc HWCaps feature.

    Recently we've switched to the currently supported Glibc HWCaps feature. Opt-in libraries of packages built with -march=x86-64-v3 and installed to /usr/lib64/glibc-hwcaps/x86-64-v3/. This is actually a slight downgrade over our previous solution as x86-64-v3 doesn't include -maes -mfsgsbase -mpclmulqdq -mrdrnd -mxsaveopt instructions unlike haswell in order to support the AMD excavator CPUs.

    Currently we pick and benchmark packages to be selected to ship x86-64-v3 libs in addition the default x86-64 libs where there is a significant uplift in performance, or, if there is only a slight uplift in performance but the package is very commonly used.

    When we rebase off of Serpent our baseline packages will built with x86-64-v2 instead of x86-64 and we will no longer be using the Glibc HWCaps feature. Instead, we will be building select packages as both x86-64-v2 and x86-64-v3 and as such the moss package manager will be smart enough to install the x86-64-v3 built packages instead of the baseline packages when they are available and the current system supports them. E.g. moss will automatically install libpng-1.6.40-1-x86-64-v3.stone instead of libpng-1.6.40-1-x86-64-v2.stone.

We've been shipping avx2 libraries for years (known as legacy Glibc HWCaps) built with -march=haswell and installed to /usr/lib64/haswell which we also patched to be compatible with AMD CPUs (zen1 and newer) for opt-in packages. This was based off Clear Linux work that was upstreamed into glibc.

There was a bit of contention with the Clear Linux work as it exclusively worked on Intel CPUs and not AMD, whilst we patched this behavior in Solus. This in part, lead the creation of the vendor agnostic x86-64-v{2,3,4} microarch levels and the current Glibc HWCaps feature.

Recently we've switched to the currently supported Glibc HWCaps feature. Opt-in libraries of packages built with -march=x86-64-v3 and installed to /usr/lib64/glibc-hwcaps/x86-64-v3/. This is actually a slight downgrade over our previous solution as x86-64-v3 doesn't include -maes -mfsgsbase -mpclmulqdq -mrdrnd -mxsaveopt instructions unlike haswell in order to support the AMD excavator CPUs.

Currently we pick and benchmark packages to be selected to ship x86-64-v3 libs in addition the default x86-64 libs where there is a significant uplift in performance, or, if there is only a slight uplift in performance but the package is very commonly used.

When we rebase off of Serpent our baseline packages will built with x86-64-v2 instead of x86-64 and we will no longer be using the Glibc HWCaps feature. Instead, we will be building select packages as both x86-64-v2 and x86-64-v3 and as such the moss package manager will be smart enough to install the x86-64-v3 built packages instead of the baseline packages when they are available and the current system supports them. E.g. moss will automatically install libpng-1.6.40-1-x86-64-v3.stone instead of libpng-1.6.40-1-x86-64-v2.stone.

    Does this mean that I have to worry that my old hardware might not be supported by Solus 5 any more?

      • [deleted]

      • Post #5

      Sebastian Run ld.so --help, the highest supported target is found in the Subdirectories of glibc-hwcaps directories section.

        joebonrichie
        Did the Solus team consider a more conservative approach, choosing something in between x86-64 and x86-64-v2?
        I'm sure -march=x86-64-v2 will not be that much faster compared to -march=nocona -mtune=generic -msahf


        Yes, I like my beautiful retro system, it's my daily driver. And it's not as terribly slow or noisy as some might imagine. It does not cursed by Vulnerabilities, it does not have super secret spy cores build-in, it does not throttle, does not overheat, the browser is always snappy, it have excellent compatibility with the old tech and professional audio.

        $ env LANGUAGE=en_US.UTF-8 lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         40 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  2
  On-line CPU(s) list:   0,1
Vendor ID:               AuthenticAMD
  Model name:            AMD Athlon(tm) Dual Core Processor 4450e
    CPU family:          15
    Model:               107
    Thread(s) per core:  1
    Core(s) per socket:  2
    Socket(s):           1
    Stepping:            2
    BogoMIPS:            4017,49
    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 rdtscp lm 3dnowext 3dnow rep_good nopl cpuid extd_apicid pni cx16 lahf_lm cmp_legacy
                          svm extapic cr8_legacy 3dnowprefetch vmmcall lbrv
Virtualization features: 
  Virtualization:        AMD-V
Caches (sum of all):     
  L1d:                   128 KiB (2 instances)
  L1i:                   128 KiB (2 instances)
  L2:                    1 MiB (2 instances)
NUMA:                    
  NUMA node(s):          1
  NUMA node0 CPU(s):     0,1
Vulnerabilities:         
  Gather data sampling:  Not affected
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Not affected
  Retbleed:              Not affected
  Spec rstack overflow:  Not affected
  Spec store bypass:     Not affected
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
  Srbds:                 Not affected
  Tsx async abort:       Not affected

            SilverBird775 Did the Solus team consider a more conservative approach, choosing something in between x86-64 and x86-64-v2?

            Yes, we did consider multiple feature levels when we were choosing what CPU microarchitecture level to support. x86-64-v2 was chosen because it's old enough that the overwhelming majority of computers still in use today are at that level or above. Virtually all CPUs newer than 2009 support that feature level with the exception of Intel Atoms which only gained it in 2013 (and let's be real, Atom CPUs older than that were never pleasant to use even when they were new). x86-64-v2 is a nice common choice that sees widespread use as a target for the industry and is already a fairly conservative target for us. It is not a goal of Solus to provide support for all possible hardware into perpetuity, there are other distros for whom that is an explicit goal.

            SilverBird775 it does not have super secret spy cores build-in

            It will also sooner than later not be able to run Solus. I think you'll need to make a decision soon about whether you want to:

            • Upgrade your CPU/mobo/ram/other hardware as needed in order to be on a more modern CPU (there are boards that support open source firmware that allow disabling the Intel ME, for example). This will allow you to continue using Solus.
            • Find a distro that more closely aligns with your desires to keep all possible hardware alive and/or is more focused on protecting against potential hardware backdoors. Neither of these are goals of Solus.