toolchain/57611: ATF test runs on non-MULTIPROCESSOR machines take way too long

[martin%NetBSD.org@localhost]

>Number:         57611
>Category:       toolchain
>Synopsis:       ATF test runs on non-MULTIPROCESSOR machines take way too long
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 08 17:30:00 +0000 2023
>Originator:     Martin Husemann
>Release:        NetBSD 10.99.8
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD martins.aprisoft.de 10.99.8 NetBSD 10.99.8 (GENERIC) #192: Thu Sep 7 19:20:26 CEST 2023 martin%martins.aprisoft.de@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:

Full ATF test runs are extremely slow on real hardware even with CPUs of GHz
clock rate if there is only a single CPU. Most part of this is spent in
ipsec tests. Multiprocessor machines, even with slower CPUs, finish the
run way faster.

For example my evbarmv5 tests at https://www.netbsd.org/~martin/evbarm-atf
take ~6.5h for one run now (single core 1200.000 MHz ARM9E-S V5TE).
Compare a dual cpu sparc64 machine with slightly slower cpu (but beter
caches): https://www.netbsd.org/~martin/sparc64-atf/ which needs
like 3.5h (UltraSPARC-IIIi @ 1002 MHz).

Nearly sounds like our ATF tests would be CPU bound, but that is by far
not the case.

>How-To-Repeat:
s/a

>Fix:
Use atf vars to reduce the default number of tests or skip especially heavy
weight ones?
Check number of CPUs in heavy rump multi-host tests and simplify or skip?