#
f63a9f15 |
|
16-Jan-2023 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Cover ZT in the FP stress test Hook up the newly added zt-test program in the FPSIMD stress tests, start a copy per CPU when SME2 is supported. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221208-arm64-sme2-v4-15-f2fa0aef982f@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
67f49869 |
|
27-Dec-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Skip non-power of 2 SVE vector lengths in fp-stress As documented in issue C215 in the known issues list for DDI0487I.a [1] Arm will be making a retroactive change to SVE to remove the possibility of selecting non power of two vector lengths. This has no impact on existing physical implementations but most virtual implementations have implemented the full range of permissible vector lengths. Given how demanding fp-stress is for these implementations update to only attempt to enumerate the power of two vector lengths, reducing the load created on existing virtual implementations and only exercising the functionality that will be seen in physical implementations. [1] https://developer.arm.com/documentation/102105/ia-00/ Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221220-arm64-fp-stress-pow2-v1-1-d0ce756b57af@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
c4e8720f |
|
29-Nov-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Allow epoll_wait() to return more than one result When everything is starting up we are likely to have a lot of child processes producing output at once. This means that we can reduce overhead a bit by allowing epoll_wait() to return more than one descriptor at once, it cuts down on the number of system calls we need to do which on virtual platforms where the syscall overhead is a bit more noticable and we're likely to have a lot more children active can make a small but noticable difference. On physical platforms the relatively small number of processes being run and vastly improved speeds push the effects of this change into the noise. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221129215926.442895-4-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
|
#
92145d88 |
|
29-Nov-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Don't drain output while spawning children Now we hold execution of the stress test programs until all children are started there is no need to drain output while that is happening. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221129215926.442895-3-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
|
#
98102a2c |
|
29-Nov-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Hold fp-stress children until they're all spawned At present fp-stress has a bit of a thundering herd problem since the children it spawns start running immediately, meaning that they can start starving the parent process of CPU before it has even started all the children. This is much more severe on virtual platforms since they tend to support far more SVE and SME vector lengths, be slower in general and for some have issues with performance when simulating multiple CPUs. We can mitigate this problem by having all the child processes block before starting the test program, meaning that we at least have all the child processes started before we start heavily using CPU. We still have the same load issues while waiting for the actual stress test programs to start up and produce output but they're at least all ready to go before that kicks in, resulting in substantial reductions in overall runtime on some of the severely affected systems. One test was showing about 20% improvement. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221129215926.442895-2-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
|
#
64297898 |
|
23-Nov-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Set test names prior to starting children Since we now flush output immediately on starting children we should ensure that the child name is set beforehand so that any output that does get flushed from the newly created child has the name of the child attached. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221124120722.150988-1-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
|
#
3e02f57b |
|
17-Oct-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Provide progress messages when signalling children Especially when the test is configured to run for a longer time it can be reassuring to users to see that the supervising program is running OK so provide a message every second when the output timer expires. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221017144553.773176-3-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
|
#
3a38ef2b |
|
17-Oct-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Check that all children are producing output in fp-stress Currently we don't have an explicit check that when it's been a second since we have seen output produced from the test programs starting up that means all of them are running and we should start both sending signals and timing out. This is not reliable, especially on very heavily loaded systems where the test programs might take longer than a second to run. We do skip sending signals to children that have not produced output yet so we won't cause them to exit unexpectedly by sending a signal but this can create confusion when interpreting output, for example appearing to show the tests running for less time than expected or appearing to show missed signal deliveries. Avoid issues by explicitly checking that we have seen output from all the child processes before we start sending signals or counting test run time. This is especially likely on virtual platforms with large numbers of vector lengths supported since the platforms are slow and there will be a lot of tasks per CPU. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221017144553.773176-2-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
|
#
a7119874 |
|
21-Sep-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Handle EINTR while reading data from children Currently we treat any error when reading from the child as a failure and don't read any more output from that child as a result. This ignores the fact that it is valid for read() to return EINTR as the error code if there is a signal pending so we could stop handling the output of children, especially during exit when we will get some SIGCHLD signals delivered to us. Fix this by pulling the read handling out into a separate function which returns a flag if reads should be continued and wrapping it in a loop. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220921181345.618085-4-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
dd72dd7c |
|
21-Sep-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Flag fp-stress as exiting when we begin finishing up Once we have started exiting the termination handler will have the same effect as what we're already running so set the termination flag at that point. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220921181345.618085-3-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
c38d381f |
|
21-Sep-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Don't repeat termination handler for fp-stress When fp-stress gets a termination signal it sets a flag telling itself to exit and sends a termination signal to all the children. If the flag is set then don't bother repeating this process, it isn't going to accomplish anything other than consume CPU time which can be an issue when running in emulation. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220921181345.618085-2-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
537addee |
|
07-Sep-2022 |
Colin Ian King <colin.i.king@gmail.com> |
kselftest/arm64: Fix spelling misakes of signal names There are a couple of spelling mistakes of signame names. Fix them. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20220907170902.687340-1-colin.i.king@gmail.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
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 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>
|