linux/tools/perf/tests/shell, branch for-next

perf/test: fix perf ftrace test on s390

2024-11-22T21:36:44Z

On s390 the perf test case ftrace sometimes fails as follows: # ./perf test ftrace 79: perf ftrace tests : FAILED! # The failure depends on the kernel .config file. Some configurations always work fine, some do not. The ftrace profile test mostly fails, because the ring buffer was not large enough, and some lines (especially the interesting ones with nanosleep in it) where dropped. To achieve success for all tested kernel configurations, enlarge the buffer to store the traces completely without wrapping. The default buffer size is too small for all kernel configurations. Set the buffer size of for the ftrace profile test to 16 MB. Output after: # ./perf test ftrace 79: perf ftrace tests : Ok # Signed-off-by: Thomas Richter Acked-by: Namhyung Kim Cc: agordeev@linux.ibm.com Cc: gor@linux.ibm.com Cc: hca@linux.ibm.com Cc: sumanthk@linux.ibm.com Link: https://lore.kernel.org/r/20241119064856.641446-1-tmricht@linux.ibm.com Suggested-by: Sven Schnelle Suggested-by: Namhyung Kim Signed-off-by: Namhyung Kim

perf tests: Make leader sampling test work without branch event

2024-11-16T19:30:39Z

Arm a57 only has speculative branch events so this test fails there. The test doesn't depend on branch instructions so change it to instructions which is pretty much guaranteed to be everywhere. The test_branch_counter() test above already tests for the existence of the branches event and skips if its not present. Reviewed-by: Ian Rogers Signed-off-by: James Clark Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Dapeng Mi Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Veronika Molnarova Link: https://lore.kernel.org/r/20241115161600.228994-1-james.clark@linaro.org Signed-off-by: Arnaldo Carvalho de Melo

perf test shell trace_exit_race: Use --no-comm to avoid cases where COMM isn't resolved

2024-11-16T19:30:32Z

The purpose of this test is to test for races in the exit of 'perf trace' missing the last events, it was failing when the COMM wasn't resolved either because we missed some PERF_RECORD_COMM or somehow raced on getting it from procfs. Add --no-comm to the 'perf trace' command line so that we get a consistent, pid only output, which allows the test to achieve its goal. This is the output from 'perf trace --no-comm -e syscalls:sys_enter_exit_group': 0.000 21953 syscalls:sys_enter_exit_group() 0.000 21955 syscalls:sys_enter_exit_group() 0.000 21957 syscalls:sys_enter_exit_group() 0.000 21959 syscalls:sys_enter_exit_group() 0.000 21961 syscalls:sys_enter_exit_group() 0.000 21963 syscalls:sys_enter_exit_group() 0.000 21965 syscalls:sys_enter_exit_group() 0.000 21967 syscalls:sys_enter_exit_group() 0.000 21969 syscalls:sys_enter_exit_group() 0.000 21971 syscalls:sys_enter_exit_group() Now it passes: root@number:~# perf test "trace exit race" 110: perf trace exit race : Ok root@number:~# root@number:~# perf test -v "trace exit race" 110: perf trace exit race : Ok root@number:~# If we artificially make it run just 9 times instead of the 10 it runs, i.e. by manually doing: trace_shutdown_race() { for _ in $(seq 9); do that 9 is $iter, 10 in the patch, we get: root@number:~# vim ~acme/libexec/perf-core/tests/shell/trace_exit_race.sh root@number:~# perf test -v "trace exit race" --- start --- test child forked, pid 24629 Missing output, expected 10 but only got 9 ---- end(-1) ---- 110: perf trace exit race : FAILED! root@number:~# I.e. 9 'perf trace' calls produced the expected output, the inverse grep didn't show anything, so the patch provided by Howard for the previous patch kicks in and shows a more informative message. Tested-by: Howard Chu Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Benjamin Peterson Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/lkml/ZzdknoHqrJbojb6P@x1 Signed-off-by: Arnaldo Carvalho de Melo

perf test shell trace_exit_race: Show what went wrong in verbose mode

2024-11-15T15:31:01Z

If it fails we need to check what was the reason, what were the lines that didn't match the expected format, so: root@number:~# perf test -v "trace exit race" --- start --- test child forked, pid 2028724 Lines not matching the expected regexp: ' +[0-9]+\.[0-9]+ +true/[0-9]+ syscalls:sys_enter_exit_group$': 0.000 :2028750/2028750 syscalls:sys_enter_exit_group() ---- end(-1) ---- 110: perf trace exit race : FAILED! root@number:~# In this case we're not resolving the process COMM for some reason and fallback to printing just the pid/tid, this will be fixed in a followup patch. Howard Chu spotted a problem with single code surrounding a regexp, that made the test always fail, but since there were some failures when I tested (COMM not being resolved in some of the results) the end inverse grep would show some lines and thus didn't notice the single quote problem. He also provided a patch to test if less than the number of expected matches took place but all of them with the expected output, in which case the inverse grep wouldn't show anything, confusing the tester. Reviewed-by: Howard Chu Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Benjamin Peterson Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/lkml/ZzdknoHqrJbojb6P@x1 Signed-off-by: Arnaldo Carvalho de Melo

perf tests: Add test for trace output loss

2024-11-14T21:10:40Z

Add a test that checks that trace output is not lost to races. This is accomplished by tracing the exit_group syscall of "true" multiple times and checking for correct output. Signed-off-by: Benjamin Peterson Tested-by: Arnaldo Carvalho de Melo Tested-by: Howard Chu Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20241107232128.108981-3-benjamin@engflow.com [ Addressed two ShellCheck warnings ] Signed-off-by: Arnaldo Carvalho de Melo

perf test: Fix ftrace test with regex patterns

2024-11-05T06:28:25Z

During the parallel testing, I've noticed some ftrace test failures. It seems the regex pattern checks 100 msec of nanosleep with the error range of 10 msec. But sometimes it's affected by other processes and resulted in more time in the syscall. The following output shows that it took more than 120 msec and failed. Let's update the regex pattern so that it can allow more drifts. perf ftrace profile test # Total (us) Avg (us) Max (us) Count Function 121279.500 121279.500 121279.500 1 __x64_sys_clock_nanosleep 121278.400 121278.400 121278.400 1 common_nsleep 121277.800 121277.800 121277.800 1 hrtimer_nanosleep 121277.100 121277.100 121277.100 1 do_nanosleep 341760.289 56960.048 121273.400 6 schedule 176.200 25.171 31.616 7 scheduler_tick 0.923 0.923 0.923 1 native_smp_send_reschedule 345522.360 69104.472 345320.600 5 __x64_sys_execve 345486.585 69097.317 345312.700 5 do_execveat_common.isra.0 340730.300 340730.300 340730.300 1 bprm_execve 1.758 0.879 0.883 2 sched_mm_cid_before_execve 1.112 1.112 1.112 1 sched_mm_cid_after_execve ---- end(-1) ---- 81: perf ftrace tests : FAILED! Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20241102231702.2262258-1-namhyung@kernel.org Signed-off-by: Namhyung Kim

perf test: Remove cpu-list BPF cgroup counter test

2024-11-05T06:10:48Z

The cpu-list part of this testcase has proven itself to be unreliable. Sometimes, we get "" for system.slice when pinned to CPUs 0 and 1. In such case, the test fails. Since we cannot simply guarantee that any system.slice load will run on any arbitrary list of CPUs, except the whole set of all CPUs, let's rather remove the cpu-list subtest. Fixes: a84260e314029e6dc9904fd ("perf test stat_bpf_counters_cgrp: Enhance perf stat cgroup BPF counter test") Signed-off-by: Michael Petlan Cc: vmolnaro@redhat.com Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20241101102812.576425-1-mpetlan@redhat.com Signed-off-by: Namhyung Kim

Merge 'origin/master' into perf-tools-next

2024-11-04T07:18:20Z

To get the fixes in the perf-tools branch. Resolved a conflict due to RISC-V's syscall table change. Signed-off-by: Namhyung Kim

perf test: Use sqrtloop workload to test bperf event

2024-11-02T06:31:08Z

Replace `brstack` workload with `sqrtloop` workload, because `sqrtloop` workload contains fork(), which is suitable for testing the bperf event inheritance feature. Signed-off-by: Tengda Wu Cc: song@kernel.org Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20241021110201.325617-3-wutengda@huaweicloud.com Signed-off-by: Namhyung Kim

perf test: Tag parallel failing shell tests with "(exclusive)"

2024-10-28T16:32:58Z

Some shell tests compete for resources and so can't run with other tests, tag such tests. The "(exclusive)" stems from shared/exclusive to describe how the tests run as if holding a lock. For ARM/coresight tests: Suggested-by: James Clark Additional failing tests: Suggested-by: Namhyung Kim Tested-by: James Clark Signed-off-by: Ian Rogers Cc: Colin Ian King Cc: Howard Chu Cc: Weilin Wang Cc: Ilya Leoshkevich Cc: Thomas Richter Cc: Andi Kleen Cc: Dapeng Mi Cc: Athira Jajeev Cc: Michael Petlan Cc: Veronika Molnarova Link: https://lore.kernel.org/r/20241025192109.132482-6-irogers@google.com Signed-off-by: Namhyung Kim