NetBSD Problem Report #57611

From  Fri Sep  8 17:28:09 2023
Return-Path: <>
Received: from ( [])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "", Issuer " CA" (not verified))
	by (Postfix) with ESMTPS id A625F1A9239
	for <>; Fri,  8 Sep 2023 17:28:09 +0000 (UTC)
Message-Id: <>
Date: Fri,  8 Sep 2023 19:27:59 +0200 (CEST)
Subject: ATF test runs on non-MULTIPROCESSOR machines take way too long
X-Send-Pr-Version: 3.95

>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
The NetBSD Foundation, Inc.
System: NetBSD 10.99.8 NetBSD 10.99.8 (GENERIC) #192: Thu Sep 7 19:20:26 CEST 2023 amd64
Architecture: x86_64
Machine: amd64

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
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): 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.


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?

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD:,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2023 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.