kernel/linux.git/tools/perf/tests/shell/record.sh, branch v7.0-rc7

perf test record.sh: Fix shellcheck warning

2026-02-08T14:29:58+00:00

Add quotes to avoid the following warning: ``` In tests/shell/record.sh line 264: [ $(uname -m) = "s390x" ] && { ^---------^ SC2046 (warning): Quote this to prevent word splitting. For more information: https://www.shellcheck.net/wiki/SC2046 -- Quote this to prevent word splitt... ``` Fixes: c73a56ed3c97ae65 ("perf test: Fix test case Leader sampling on s390") Signed-off-by: Ian Rogers Cc: Namhyung Kim Cc: Thomas Richter Signed-off-by: Arnaldo Carvalho de Melo

perf test: Fix test case Leader sampling on s390

2026-02-06T21:40:24+00:00

The subtest 'Leader sampling' some time fails on s390. - for z/VM guest: Disable the test for z/VM guest. There is no CPU Measurement facility to run the test successfully. - for LPAR: Use correct event names. A detailed analysis follows here: Now to the debugging and investigation: 1. With command perf record -e '{cycles,cycles}:S' -- .... the first cycles event starts sampling. On s390 this sets up sampling with a frequency of 4000 Hz. This translates to hardware sample rate of 1377000 instructions per micro-second to meet a frequency of 4000 HZ. 2. With first event cycles now sampling into a hardware buffer, an interrupt is triggered each time a sampling buffer gets full. The interrupt handler is then invoked and debug output shows the processing of samples. The size of one hardware sample is 32 bytes. With an interrupt triggered when the hardware buffer page of 4KB gets full, the interrupt handler processes 128 samples. (This is taken from s390 specific fast debug data gathering) 2025-11-07 14:35:51.977248 000003ffe013cbfa \ perf_event_count_update event->count 0x0 count 0x1502e8 2025-11-07 14:35:51.977248 000003ffe013cbfa \ perf_event_count_update event->count 0x1502e8 count 0x1502e8 2025-11-07 14:35:51.977248 000003ffe013cbfa \ perf_event_count_update event->count 0x2a05d0 count 0x1502e8 2025-11-07 14:35:51.977252 000003ffe013cbfa \ perf_event_count_update event->count 0x3f08b8 count 0x1502e8 2025-11-07 14:35:51.977252 000003ffe013cbfa \ perf_event_count_update event->count 0x540ba0 count 0x1502e8 2025-11-07 14:35:51.977253 000003ffe013cbfa \ perf_event_count_update event->count 0x690e88 count 0x1502e8 2025-11-07 14:35:51.977254 000003ffe013cbfa \ perf_event_count_update event->count 0x7e1170 count 0x1502e8 2025-11-07 14:35:51.977254 000003ffe013cbfa \ perf_event_count_update event->count 0x931458 count 0x1502e8 2025-11-07 14:35:51.977254 000003ffe013cbfa \ perf_event_count_update event->count 0xa81740 count 0x1502e8 3. The value is constantly increasing by the number of instructions executed to generate a sample entry. This is the first line of the pairs of lines. count 0x1502e8 --> 1377000 # perf script | grep 1377000 | wc -l 214 # perf script | wc -l 428 # That is 428 lines in total, and half of the lines contain value 1377000. 4. The second event cycles is opened against the counting PMU, which is an independent PMU and is not interrupt driven. Once enabled it runs in the background and keeps running, incrementing silently about 400+ counters. The counter values are read via assembly instructions. This second counter PMU's read call back function is called when the interrupt handler of the sampling facility processes each sample. The function call sequence is: perf_event_overflow() +--> __perf_event_overflow() +--> __perf_event_output() +--> perf_output_sample() +--> perf_output_read() +--> perf_output_read_group() for_each_sibling_event(sub, leader) { values[n++] = perf_event_count(sub, self); printk("%s sub %p values %#lx\n", __func__, sub, values[n-1]); } The last function perf_event_count() is invoked on the second event cylces *on* the counting PMU. An added printk statement shows the following lines in the dmesg output: # dmesg|grep perf_output_read_group |head -10 [ 332.368620] perf_output_read_group sub 00000000d80b7c1f values 0x3a80917 (1) [ 332.368624] perf_output_read_group sub 00000000d80b7c1f values 0x3a86c7f (2) [ 332.368627] perf_output_read_group sub 00000000d80b7c1f values 0x3a89c15 (3) [ 332.368629] perf_output_read_group sub 00000000d80b7c1f values 0x3a8c895 (4) [ 332.368631] perf_output_read_group sub 00000000d80b7c1f values 0x3a8f569 (5) [ 332.368633] perf_output_read_group sub 00000000d80b7c1f values 0x3a9204b [ 332.368635] perf_output_read_group sub 00000000d80b7c1f values 0x3a94790 [ 332.368637] perf_output_read_group sub 00000000d80b7c1f values 0x3a9704b [ 332.368638] perf_output_read_group sub 00000000d80b7c1f values 0x3a99888 # This correlates with the output of # perf report -D | grep 'id 00000000000000'|head -10 ..... id 0000000000000006, value 00000000001502e8, lost 0 ..... id 000000000000000e, value 0000000003a80917, lost 0 --> line (1) above ..... id 0000000000000006, value 00000000002a05d0, lost 0 ..... id 000000000000000e, value 0000000003a86c7f, lost 0 --> line (2) above ..... id 0000000000000006, value 00000000003f08b8, lost 0 ..... id 000000000000000e, value 0000000003a89c15, lost 0 --> line (3) above ..... id 0000000000000006, value 0000000000540ba0, lost 0 ..... id 000000000000000e, value 0000000003a8c895, lost 0 --> line (4) above ..... id 0000000000000006, value 0000000000690e88, lost 0 ..... id 000000000000000e, value 0000000003a8f569, lost 0 --> line (5) above Summary: - Above command starts the CPU sampling facility, with runs interrupt driven when a 4KB page is full. An interrupt processes the 128 samples and calls eventually perf_output_read_group() for each sample to save it in the event's ring buffer. - At that time the CPU counting facility is invoked to read the value of the event cycles. This value is saved as the second value in the sample_read structure. - The first and odd lines in the perf script output displays the period value between 2 samples being created by hardware. It is the number of instructions executes before the hardware writes a sample. - The second and even lines in the perf script output displays the number of CPU cycles needed to process each sample and save it in the event's ring buffer. These 2 different values can never be identical on s390. Since event leader sampling is not possible on s390 the perf tool will return EOPNOTSUPP soon. Perpare the test case for that. Suggested-by: James Clark Reviewed-by: Jan Polensky Signed-off-by: Thomas Richter Tested-by: Jan Polensky Cc: Alexander Gordeev Cc: Heiko Carstens Cc: Namhyung Kim Cc: Sumanth Korikkar Cc: Vasily Gorbik Signed-off-by: Arnaldo Carvalho de Melo

perf record: Add auto counter reload parse and regression tests

2025-10-03T19:49:51+00:00

Include event parsing and regression tests for auto counter reload and ratio-to-prev event term. Reviewed-by: Ian Rogers Signed-off-by: Thomas Falcon Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Dapeng Mi Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo

perf test: Add basic callgraph test to record testing

2025-06-30T16:11:39+00:00

Give some basic perf record callgraph coverage. Signed-off-by: Ian Rogers Reviewed-by: James Clark Tested-by: Thomas Richter Link: https://lore.kernel.org/r/20250628015553.1270748-1-irogers@google.com Signed-off-by: Namhyung Kim

perf tests record: Add basic uid filtering test

2025-06-09T18:18:18+00:00

Based on the system-wide test with changes around how failure is handled as BPF permissions are a bigger issue than perf event paranoia. Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250604174545.2853620-6-irogers@google.com Signed-off-by: Namhyung Kim

perf test: Allow tolerance for leader sampling test

2025-05-15T15:55:51+00:00

There is a known issue that the leader sampling is inconsistent, since throttle only affect leader, not the slave. The detail is in [1]. To maintain test coverage, this patch sets a tolerance rate of 80% to accommodate the throttled samples and prevent test failures due to throttling. [1] lore.kernel.org/20250328182752.769662-1-ctshao@google.com Suggested-by: Ian Rogers Suggested-by: Thomas Richter Reviewed-by: Ian Rogers Signed-off-by: Chun-Tse Shao Co-developed-by: Thomas Richter Signed-off-by: Thomas Richter Tested-by: Thomas Richter Cc: Alexander Gordeev Cc: Heiko Carstens Cc: Namhyung Kim Cc: Sumanth Korikkar Cc: Vasily Gorbik Link: https://lore.kernel.org/r/20250430140611.599078-1-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo

perf tests record: Cleanup improvements

2025-04-25T15:32:10+00:00

Remove the script output file. Add a trap debug message. Minor style consistency changes. Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250410173631.1713627-2-irogers@google.com Cc: Mark Rutland Cc: Levi Yun Cc: Dominique Martinet Cc: Howard Chu Cc: Tengda Wu Cc: Peter Zijlstra Cc: Adrian Hunter Cc: Weilin Wang Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Cc: Hao Ge Cc: James Clark Cc: Thomas Richter Cc: Alexander Shishkin Cc: Dapeng Mi Cc: Kan Liang Cc: Xu Yang Cc: Ingo Molnar Cc: Veronika Molnarova Cc: Dr. David Alan Gilbert Cc: bpf@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-perf-users@vger.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf test: Use cycles event in perf record test for leader_sampling

2025-02-04T19:36:14+00:00

On s390 the event instructions can not be used for recording. This event is only supported by perf stat. Change the event from instructions to cycles in subtest test_leader_sampling. Signed-off-by: Thomas Richter Suggested-by: James Clark Reviewed-by: James Clark Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20250131102756.4185235-3-tmricht@linux.ibm.com Signed-off-by: Namhyung Kim

perf test: Fix perf record test for precise_max

2025-02-04T19:34:25+00:00

On s390 the event instructions can not be used for recording. This event is only supported by perf stat. Test that each event cycles and instructions supports sampling. If the event can not be sampled, skip it. Signed-off-by: Thomas Richter Suggested-by: James Clark Reviewed-by: James Clark Link: https://lore.kernel.org/r/20250131102756.4185235-2-tmricht@linux.ibm.com Signed-off-by: Namhyung Kim

perf tests: Make leader sampling test work without branch event

2024-11-16T19:30:39+00:00

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