2023-01-11 15:20:04

by Naresh Kamboju

[permalink] [raw]
Subject: [PATCH] selftests/arm64: bump timeout to 15 minutes

LKFT CI found that with the latest mainline kernel (6.1) on
some QEMU emulators and FVP, the following tests will take
longer than the kselftest framework default timeout (45 seconds) to
run and thus got terminated with TIMEOUT error:
* fp-stress - took about 11m30s
* sve-ptrace - took about 8m50s
* check_gcr_el1_cswitch - took about 6m
* check_user_mem - took about 3m
* syscall-abi - took about 5m

Current test timeouts:
not ok 29 selftests: arm64: sve-ptrace # TIMEOUT 45 seconds
not ok 36 selftests: arm64: check_gcr_el1_cswitch # TIMEOUT 45 seconds
not ok 41 selftests: arm64: check_user_mem # TIMEOUT 45 seconds
not ok 46 selftests: arm64: syscall-abi # TIMEOUT 45 seconds

Signed-off-by: Naresh Kamboju <[email protected]>
---
tools/testing/selftests/arm64/settings | 1 +
1 file changed, 1 insertion(+)
create mode 100644 tools/testing/selftests/arm64/settings

diff --git a/tools/testing/selftests/arm64/settings b/tools/testing/selftests/arm64/settings
new file mode 100644
index 000000000000..8959a5dd8ace
--- /dev/null
+++ b/tools/testing/selftests/arm64/settings
@@ -0,0 +1 @@
+timeout=900
\ No newline at end of file
--
2.30.2


2023-01-11 15:51:12

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH] selftests/arm64: bump timeout to 15 minutes

On Wed, Jan 11, 2023 at 07:59:12PM +0530, Naresh Kamboju wrote:

> LKFT CI found that with the latest mainline kernel (6.1) on
> some QEMU emulators and FVP, the following tests will take
> longer than the kselftest framework default timeout (45 seconds) to
> run and thus got terminated with TIMEOUT error:
> * fp-stress - took about 11m30s
> * sve-ptrace - took about 8m50s
> * check_gcr_el1_cswitch - took about 6m
> * check_user_mem - took about 3m
> * syscall-abi - took about 5m

We should really only be applying this to emulated platforms, all these
tests will run in a much more sensible time on physical platforms (eg,
fp-stress runs for the target of slightly more than 10s on every
physical platform I've tried it on and I've no reason to believe it'd
have problems on others). Even for emulated specific configuration
that's a bit of a moving target given the range of emulation options out
there.

I do also note that the systems you're using appear to be giving
astonishingly poor performance even for emulated platforms, for example
on my desktop here syscall-abi takes about 12s in qemu and what the FVP
internally thinks is 10s there for the default set of vector lengths
(the actual wall clock time for the FVP is more like 45s, but I'd expect
the runner to enforce the internally recorded time). Even fp-stress is
running in about 20s on qemu, though it does rather badly stress the
current versions of the FVP and start getting up to something more like
what you're reporting with 8 cores (the biggest performance issues there
are for things that stress multiple cores simultaneously).

Conincidentally I just wrote a change to the ptrace tests which will
reduce the number of cases which will reduce the I/O costs a lot if
nothing else.


Attachments:
(No filename) (1.75 kB)
signature.asc (499.00 B)
Download all attachments