Non-optimal CPU detection of zen3 using archspec

[laraPPr]

When setting up the EESSI environment on the zen3 nodes on aws/citc archspec detects zen2 instead of zen3.

[laraPPr@fair-mastodon-c6a-4xlarge-0001 ~]$ archspec cpu

zen2

[laraPPr]

[laraPPr@fair-mastodon-c6a-4xlarge-0001 ~]$ lscpu

Architecture:        x86_64

CPU op-mode(s):      32-bit, 64-bit

Byte Order:          Little Endian

CPU(s):              16

On-line CPU(s) list: 0-15

Thread(s) per core:  2

Core(s) per socket:  8

Socket(s):           1

NUMA node(s):        1

Vendor ID:           AuthenticAMD

CPU family:          25

Model:               1

Model name:          AMD EPYC 7R13 Processor

Stepping:            1

CPU MHz:             2649.988

BogoMIPS:            5299.97

Hypervisor vendor:   KVM

Virtualization type: full

L1d cache:           32K

L1i cache:           32K

L2 cache:            512K

L3 cache:            32768K

NUMA node0 CPU(s):   0-15

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 constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch topoext invpcid_single ssbd ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 invpcid rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr wbnoinvd arat npt nrip_save vaes vpclmulqdq rdpid

[laraPPr]

There is one missing CPU feature on c6a.2xlarge and c6a.4xlarge: pku

There is also an open issue in archspec on this.

[boegel]

As mentioned in #322, this in combination with #322, is a sufficient reason to switch to our homegrown archdetect alternative as default mechanism imho.

[laraPPr]

EESSI_USE_ARCHDETECT=1 source /cvmfs/pilot.eessi-hpc.org/versions/2023.06/init/bash

• c6a.2xlarge

[laraPPr@fair-mastodon-c6a-2xlarge-0001 ~]$ EESSI_USE_ARCHDETECT=1 source /cvmfs/pilot.eessi-hpc.org/versions/2023.06/init/bash

Found EESSI pilot repo @ /cvmfs/pilot.eessi-hpc.org/versions/2023.06!

2023-09-01 11:51:42 [INFO] cpupath: best match for host CPU: x86_64/amd/zen3

archdetect says x86_64/amd/zen3

Using x86_64/amd/zen3 as software subdirectory.

Using /cvmfs/pilot.eessi-hpc.org/versions/2023.06/software/linux/x86_64/amd/zen3/modules/all as the directory to be added to MODULEPATH.

Found Lmod configuration file at /cvmfs/pilot.eessi-hpc.org/versions/2023.06/software/linux/x86_64/amd/zen3/.lmod/lmodrc.lua

Initializing Lmod...

Prepending /cvmfs/pilot.eessi-hpc.org/versions/2023.06/software/linux/x86_64/amd/zen3/modules/all to $MODULEPATH...

Environment set up to use EESSI pilot software stack, have fun!

[EESSI pilot 2023.06] $ 

• c6a.4xlarge

[laraPPr@fair-mastodon-c6a-4xlarge-0001 ~]$ EESSI_USE_ARCHDETECT=1 source /cvmfs/pilot.eessi-hpc.org/versions/2023.06/init/bash

Found EESSI pilot repo @ /cvmfs/pilot.eessi-hpc.org/versions/2023.06!

2023-09-01 12:03:25 [INFO] cpupath: best match for host CPU: x86_64/amd/zen3

archdetect says x86_64/amd/zen3

Using x86_64/amd/zen3 as software subdirectory.

Using /cvmfs/pilot.eessi-hpc.org/versions/2023.06/software/linux/x86_64/amd/zen3/modules/all as the directory to be added to MODULEPATH.

Found Lmod configuration file at /cvmfs/pilot.eessi-hpc.org/versions/2023.06/software/linux/x86_64/amd/zen3/.lmod/lmodrc.lua

Initializing Lmod...

Prepending /cvmfs/pilot.eessi-hpc.org/versions/2023.06/software/linux/x86_64/amd/zen3/modules/all to $MODULEPATH...

Environment set up to use EESSI pilot software stack, have fun!

[ocaisa]

This makes me a bit nervous as I went away and read https://marcin.juszkiewicz.com.pl/2022/11/08/from-a-diary-of-aarch64-porter-arm-cpu-features-table/ (who is the author of the AArch64 SoC features table). It makes it seem like there is not a general progression in Arm space, so how are we supposed to know what code will work on which platform.

Also from the discussion in Archspec on identifying between Zen2 and Zen3 makes me wonder if there's a chance something we compile for neoverse_n1 will actually run on another neoverse_n1 since we may have unsupported instructions depending on the actual chip.