summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/arm64/fp/fp-pidbench.S
AgeCommit message (Collapse)Author
2026-01-28kselftest/arm64: Raise default number of loops in fp-pidbenchMark Brown
When fp-pidbench was originally written SVE hardware was not widely available so it was useful to run it in emulation and the default number of loops was set very low, running for less than a second on actual hardware. Now that SVE hardware is reasonably available it is very much less interesting to use emulation, bump the default number of loops up to even out a bit of the noise on real systems. On the machine I have to hand this now takes about 15s which is still a toy microbenchmark but perhaps a bit more useful. Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-28kselftest/arm64: Add a no-SVE loop after SVE in fp-pidbenchMark Brown
Some applications use SVE intermittently, one common case being where SVE is used during statup (eg, by ld.so) but then rarely if ever during the main application runtime. Add a repeat of the no SVE loop after we've done the SVE loops to fp-pidbench to capture results for that. Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2023-01-20kselftest/arm64: Remove redundant _start labels from FP testsMark Brown
There are a number of freestanding static executables used in floating point testing that have no runtime at all. These all define the main entry point as: .globl _start function _start _start: but clang's integrated assembler complains that: error: symbol '_start' is already defined due to having both a label and function directive. Remove the label to allow building with clang. No functional change. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20230111-arm64-kselftest-clang-v1-2-89c69d377727@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-12-14kselftest/arm64: Add pidbench for floating point syscall casesMark Brown
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>