In such bug I proposed to run mpi with true and skip
the tests if it fails.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057556#34

Maybe a similar idea would work here as well.


We can try that. As you suggested in the other bug, it might be quirk of 
openmpi we're facing.
openmpi distinguishs sockets, cores, slots, hwthread.  On one system two cores 
might be found in one socket, on another each core might have its own socket.

To track that, what does `lscpu` report on your failing system?
(the thread,core,socket lines are probably the relevant ones)

It's an AWS machine of type m6a.large. These are the most relevant specs.

    Thread(s) per core:   2
    Core(s) per socket:   1
    Socket(s):            1

(full lscpu attached in case it matters)

So it seems to have "one core, two threads". I can try changing the n=2 
parameter
in the ipp.Cluster invocation to n=1 and tell you if there is any change,
if it helps. I don't think that will make things worse in any case.

Thanks.
Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Address sizes:                        48 bits physical, 48 bits virtual
Byte Order:                           Little Endian
CPU(s):                               2
On-line CPU(s) list:                  0,1
Vendor ID:                            AuthenticAMD
BIOS Vendor ID:                       Advanced Micro Devices, Inc.
Model name:                           AMD EPYC 7R13 Processor
BIOS Model name:                      AMD EPYC 7R13 Processor  CPU @ 2.6GHz
BIOS CPU family:                      107
CPU family:                           25
Model:                                1
Thread(s) per core:                   2
Core(s) per socket:                   1
Socket(s):                            1
Stepping:                             1
BogoMIPS:                             5299,99
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 rdpru wbnoinvd arat npt nrip_save vaes vpclmulqdq rdpid
Hypervisor vendor:                    KVM
Virtualization type:                  full
L1d cache:                            32 KiB (1 instance)
L1i cache:                            32 KiB (1 instance)
L2 cache:                             512 KiB (1 instance)
L3 cache:                             4 MiB (1 instance)
NUMA node(s):                         1
NUMA node0 CPU(s):                    0,1
Vulnerability Gather data sampling:   Not affected
Vulnerability Itlb multihit:          Not affected
Vulnerability L1tf:                   Not affected
Vulnerability Mds:                    Not affected
Vulnerability Meltdown:               Not affected
Vulnerability Mmio stale data:        Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed:               Not affected
Vulnerability Spec rstack overflow:   Mitigation; safe RET, no microcode
Vulnerability Spec store bypass:      Mitigation; Speculative Store Bypass 
disabled via prctl
Vulnerability Spectre v1:             Mitigation; usercopy/swapgs barriers and 
__user pointer sanitization
Vulnerability Spectre v2:             Mitigation; Retpolines; IBPB conditional; 
IBRS_FW; STIBP always-on; RSB filling; PBRSB-eIBRS Not affected; BHI Not 
affected
Vulnerability Srbds:                  Not affected
Vulnerability Tsx async abort:        Not affected

Reply via email to