kernel/tools/testing/selftests/arm64/fp, branch linux-6.2.y

selftests: arm64: Fix incorrect kernel headers search path

2023-03-10T08:29:37Z

commit 7482c19173b7eb044d476b3444d7ee55bc669d03 upstream. Use $(KHDR_INCLUDES) as lookup path for kernel headers. This prevents building against kernel headers from the build environment in scenarios where kernel headers are installed into a specific output directory (O=...). Signed-off-by: Mathieu Desnoyers Cc: Shuah Khan Cc: linux-kselftest@vger.kernel.org Cc: Ingo Molnar Cc: # 5.18+ Acked-by: Shuah Khan Acked-by: Catalin Marinas Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman

kselftest/arm64: Allow epoll_wait() to return more than one result

2022-12-01T17:46:45Z

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 Link: https://lore.kernel.org/r/20221129215926.442895-4-broonie@kernel.org Signed-off-by: Will Deacon

kselftest/arm64: Don't drain output while spawning children

2022-12-01T17:46:45Z

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 Link: https://lore.kernel.org/r/20221129215926.442895-3-broonie@kernel.org Signed-off-by: Will Deacon

kselftest/arm64: Hold fp-stress children until they're all spawned

2022-12-01T17:46:45Z

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 Link: https://lore.kernel.org/r/20221129215926.442895-2-broonie@kernel.org Signed-off-by: Will Deacon

kselftest/arm64: Set test names prior to starting children

2022-11-25T12:21:25Z

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 Link: https://lore.kernel.org/r/20221124120722.150988-1-broonie@kernel.org Signed-off-by: Will Deacon

kselftest/arm64: Provide progress messages when signalling children

2022-11-08T16:03:19Z

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 Link: https://lore.kernel.org/r/20221017144553.773176-3-broonie@kernel.org Signed-off-by: Will Deacon

kselftest/arm64: Check that all children are producing output in fp-stress

2022-11-08T16:03:19Z

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 Link: https://lore.kernel.org/r/20221017144553.773176-2-broonie@kernel.org Signed-off-by: Will Deacon

kselftest/arm64: Handle EINTR while reading data from children

2022-09-29T17:12:37Z

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 Link: https://lore.kernel.org/r/20220921181345.618085-4-broonie@kernel.org Signed-off-by: Catalin Marinas

kselftest/arm64: Flag fp-stress as exiting when we begin finishing up

2022-09-29T17:12:37Z

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 Link: https://lore.kernel.org/r/20220921181345.618085-3-broonie@kernel.org Signed-off-by: Catalin Marinas

kselftest/arm64: Don't repeat termination handler for fp-stress

2022-09-29T17:12:37Z

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 Link: https://lore.kernel.org/r/20220921181345.618085-2-broonie@kernel.org Signed-off-by: Catalin Marinas