linux-kernel - Re: [PATCH] selftests/arm64: bump timeout to 15 minutes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Y77Vynb+rhiQMJQB@sirena.org.uk>
Date:   Wed, 11 Jan 2023 15:29:14 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Naresh Kamboju <naresh.kamboju@...aro.org>
Cc:     linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        lkft-triage@...ts.linaro.org, skhan@...uxfoundation.org,
        will@...nel.org, anders.roxell@...aro.org
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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)