| fd5c2c6f | 29-Aug-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: kselftest harness for FP stress tests
Currently the stress test programs for floating point context switching are
run by hand, there are extremely simplistic harnesses which run som
kselftest/arm64: kselftest harness for FP stress tests
Currently the stress test programs for floating point context switching are
run by hand, there are extremely simplistic harnesses which run some copies
of each test individually but they are not integrated into kselftest and
with SVE and SME they only run with whatever vector length the process has
by default. This is hassle when running the tests and means that they're
not being run at all by CI systems picking up kselftest.
In order to improve our coverage and provide a more convenient interface
provide a harness program which starts enough stress test programs up to
cause context switching and runs them for a set period. If only FPSIMD is
available in the system we start two copies of the FPSIMD stress test per
CPU, otherwise we start one copy of the FPSIMD and then start the SVE,
streaming SVE and ZA tests once per CPU for each available VL they have
to run on. We then run for a set period monitoring for any errors
reported by the test programs before cleanly terminating them.
In order to provide additional coverage of signal handling and some extra
noise in the scheduling we send a SIGUSR2 to the stress tests once a
second, the tests will count the number of signals they get.
Since kselftest is generally expected to run quickly we by default only run
for ten seconds. This is enough to show if there is anything cripplingly
wrong but not exactly a thorough soak test, for interactive and more
focused use a command line option -t N is provided which overrides the
length of time to run for (specified in seconds) and if 0 is specified then
there is no timeout and the test must be manually terminated. The timeout
is counted in seconds with no output, this is done to account for the
potentially slow startup time for the test programs on virtual platforms
which tend to struggle during startup as they are both slow and tend to
support a wide range of vector lengths.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220829154452.824870-5-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| d47d8a5e | 07-Sep-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Install signal handlers before output in FP stress tests
To interface more robustly with other processes install the signal handers
in the floating point stress tests before we prod
kselftest/arm64: Install signal handlers before output in FP stress tests
To interface more robustly with other processes install the signal handers
in the floating point stress tests before we produce any output, this
means that a parent process can know that if it has seen any output from
the test then the test is ready to handle incoming signals.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220906220056.820295-1-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| 05a5980f | 29-Aug-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Count SIGUSR2 deliveries in FP stress tests
Currently the floating point stress tests mostly support testing that the
data they are checking can be disrupted from a signal handler t
kselftest/arm64: Count SIGUSR2 deliveries in FP stress tests
Currently the floating point stress tests mostly support testing that the
data they are checking can be disrupted from a signal handler triggered by
SIGUSR1. This is not properly implemented for all the tests and in testing
is frequently modified to just handle the signal without corrupting data in
order to ensure that signal handling does not corrupt data. Directly support
this usage by installing a SIGUSR2 handler which simply counts the signal
delivery.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220829154452.824870-3-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| aca43ad5 | 27-Apr-2022 |
Mark Brown <broonie@kernel.org> |
selftests/arm64: Fix O= builds for the floating point tests
Currently the arm64 floating point tests don't support out of tree builds
due to two quirks of the kselftest build system. One is that whe
selftests/arm64: Fix O= builds for the floating point tests
Currently the arm64 floating point tests don't support out of tree builds
due to two quirks of the kselftest build system. One is that when building
a program from multiple files we shouldn't separately compile the main
program to an object file as that will result in the pattern rule not
matching when adjusted for the output directory. The other is that we also
need to include $(OUTPUT) in the names of the binaries when specifying the
dependencies in order to ensure that they get picked up with O=.
Rewrite the dependencies for the executables to fix these issues. The
kselftest build system will ensure OUTPUT is always defined.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220427181954.357975-5-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| 399cf0a3 | 27-Apr-2022 |
Mark Brown <broonie@kernel.org> |
selftests/arm64: Clean the fp helper libraries
We provide a couple of object files with helpers linked into several of
the test programs, ensure they are cleaned.
Signed-off-by: Mark Brown <broonie
selftests/arm64: Clean the fp helper libraries
We provide a couple of object files with helpers linked into several of
the test programs, ensure they are cleaned.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220427181954.357975-4-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| 3a23a42d | 27-Apr-2022 |
Mark Brown <broonie@kernel.org> |
selftests/arm64: Define top_srcdir for the fp tests
Some of the rules in lib.mk use a top_srcdir variable to figure out where
the top of the kselftest tree is, provide it.
Signed-off-by: Mark Brown
selftests/arm64: Define top_srcdir for the fp tests
Some of the rules in lib.mk use a top_srcdir variable to figure out where
the top of the kselftest tree is, provide it.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220427181954.357975-3-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| a59f7a7f | 27-Apr-2022 |
Mark Brown <broonie@kernel.org> |
selftests/arm64: Use TEST_GEN_PROGS_EXTENDED in the FP Makefile
The kselftest lib.mk provides a default all target which builds additional
programs from TEST_GEN_PROGS_EXTENDED, use that rather than
selftests/arm64: Use TEST_GEN_PROGS_EXTENDED in the FP Makefile
The kselftest lib.mk provides a default all target which builds additional
programs from TEST_GEN_PROGS_EXTENDED, use that rather than using
TEST_PROGS_EXTENDED which is for programs that don't need to be built like
shell scripts. Leave fpsimd-stress and sve-stress there since they are
scripts.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220427181954.357975-2-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| 212b0426 | 19-Apr-2022 |
Mark Brown <broonie@kernel.org> |
selftests/arm64: Add a testcase for handling of ZA on clone()
Add a small testcase that attempts to do a clone() with ZA enabled and
verifies that it remains enabled with the same contents. We only
selftests/arm64: Add a testcase for handling of ZA on clone()
Add a small testcase that attempts to do a clone() with ZA enabled and
verifies that it remains enabled with the same contents. We only check
one word in one horizontal vector of ZA since there's already other tests
that check for data corruption more broadly, we're just looking to make
sure that ZA is still enabled and it looks like the data got copied.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220419112247.711548-40-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| 86c8888f | 19-Apr-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Add coverage for the ZA ptrace interface
Add some basic coverage for the ZA ptrace interface, including walking
through all the vector lengths supported in the system. Unlike SVE
d
kselftest/arm64: Add coverage for the ZA ptrace interface
Add some basic coverage for the ZA ptrace interface, including walking
through all the vector lengths supported in the system. Unlike SVE
doing syscalls does not discard the ZA state so when we set data in ZA
we run the child process briefly, having it add one to each byte in ZA
in order to validate that both the vector size and data are being read
and written as expected when the process runs.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20220419112247.711548-38-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| 4126bde0 | 19-Apr-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: sme: Provide streaming mode SVE stress test
One of the features of SME is the addition of streaming mode, in which we
have access to a set of streaming mode SVE registers at the SME
kselftest/arm64: sme: Provide streaming mode SVE stress test
One of the features of SME is the addition of streaming mode, in which we
have access to a set of streaming mode SVE registers at the SME vector
length. Since these are accessed using the SVE instructions let's reuse
the existing SVE stress test for testing with a compile time option for
controlling the few small differences needed:
- Enter streaming mode immediately on starting the program.
- In streaming mode FFR is removed so skip reading and writing FFR.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20220419112247.711548-33-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| e8c44514 | 19-Apr-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: sme: Add SME support to vlset
The Scalable Matrix Extenions (SME) introduces additional register state
with configurable vector lengths, similar to SVE but configured separately.
Ex
kselftest/arm64: sme: Add SME support to vlset
The Scalable Matrix Extenions (SME) introduces additional register state
with configurable vector lengths, similar to SVE but configured separately.
Extend vlset to support configuring this state with a --sme or -s command
line option.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20220419112247.711548-30-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| 82f97bcd | 04-Apr-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Validate setting via FPSIMD and read via SVE regsets
Currently we validate that we can set the floating point state via the SVE
regset and read the data via the FPSIMD regset but we
kselftest/arm64: Validate setting via FPSIMD and read via SVE regsets
Currently we validate that we can set the floating point state via the SVE
regset and read the data via the FPSIMD regset but we do not valiate that
the opposite case works as expected. Add a test that covers this case,
noting that when reading via SVE regset the kernel has the option of
returning either SVE or FPSIMD data so we need to accept both formats.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20220404090613.181272-4-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| 1fb1e285 | 04-Apr-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Remove assumption that tasks start FPSIMD only
Currently the sve-ptrace test for setting and reading FPSIMD data assumes
that the child will start off in FPSIMD only mode and that i
kselftest/arm64: Remove assumption that tasks start FPSIMD only
Currently the sve-ptrace test for setting and reading FPSIMD data assumes
that the child will start off in FPSIMD only mode and that it can use this
to read some FPSIMD mode SVE ptrace data, skipping the test if it can't.
This isn't an assumption guaranteed by the ABI and also limits how we can
use this testcase within the program. Instead skip the initial read and
just generate a FPSIMD format buffer for the write part of the test, making
the coverage more robust in the face of future kernel and test program
changes.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20220404090613.181272-3-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| 9ae279ec | 24-Jan-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Correct logging of FPSIMD register read via ptrace
There's a cut'n'paste error in the logging for our test for reading register
state back via ptrace, correctly say that we did a re
kselftest/arm64: Correct logging of FPSIMD register read via ptrace
There's a cut'n'paste error in the logging for our test for reading register
state back via ptrace, correctly say that we did a read instead of a write.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20220124175527.3260234-3-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| 2c94ebed | 02-Dec-2021 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Add pidbench for floating point syscall cases
Since it's likely to be useful for performance work with SVE let's have a
pidbench that gives us some numbers for consideration. In ord
kselftest/arm64: Add pidbench for floating point syscall cases
Since it's likely to be useful for performance work with SVE let's have a
pidbench that gives us some numbers for consideration. In order to ensure
that we test exactly the scenario we want this is written in assembly - if
system libraries use SVE this would stop us exercising the case where the
process has never used SVE.
We exercise three cases:
- Never having used SVE.
- Having used SVE once.
- Using SVE after each syscall.
by spinning running getpid() for a fixed number of iterations with the
time measured using CNTVCT_EL0 reported on the console. This is obviously
a totally unrealistic benchmark which will show the extremes of any
performance variation but equally given the potential gotchas with use of
FP instructions by system libraries it's good to have some concrete code
shared to make it easier to compare notes on results.
Testing over multiple SVE vector lengths will need to be done with vlset
currently, the test could be extended to iterate over all of them if
desired.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20211202165107.1075259-1-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|