Re: [PATCH v5 18/19] perf test cs-etm: Speed up disassembly test

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Reducing `--stop-sample` to 2 causes extreme test flakiness due to sample exhaustion and limited branch coverage.
--

commit ef4a0ff67bea24ddbc6e5c1bb7bfc2c172bd783d
Author: James Clark <james.clark@linaro.org>

perf test cs-etm: Speed up disassembly test

This commit limits the amount of trace to decode by using exit snapshots
and reduces the objdump sample limit from 30 to 2 to speed up the
disassembly test.

> diff --git a/tools/perf/tests/shell/test_arm_coresight_disasm.sh b/tools/perf/tests/shell/test_arm_coresight_disasm.sh
> index f78dfb6bf73e3..f2fb1aa92252a 100755
> --- a/tools/perf/tests/shell/test_arm_coresight_disasm.sh
> +++ b/tools/perf/tests/shell/test_arm_coresight_disasm.sh
> @@ -43,9 +43,9 @@ branch_search='[[:space:]](bl|b(\.(eq|ne|cs|cc|mi|pl|vs|vc|hi|ls|ge|lt|gt|le|al)
>  ## Test kernel ##
>  if [ "$(id -u)" == 0 ] && [ -e /proc/kcore ]; then
>  	echo "Testing kernel disassembly"
> -	perf record -o ${perfdata} -e cs_etm//k --kcore -- touch $file > /dev/null 2>&1
> +	perf record -o ${perfdata} -e cs_etm//k --kcore -Se -m,64K -- touch $file > /dev/null 2>&1
>  	perf script -i ${perfdata} -s python:${script_path} -- \
> -		-d --stop-sample=30 -k ${perfdata}/kcore_dir/kcore 2> /dev/null > ${file}
> +		-d --stop-sample=2 -k ${perfdata}/kcore_dir/kcore 2> /dev/null > ${file}

[Severity: Medium]
Will this severe reduction in sample limit cause test flakiness?

Because sample index tracking in arm-cs-trace-disasm.py starts at -1,
setting the limit to 2 allows exactly 3 samples to be processed. The
script requires at least two branches events on the same CPU to invoke
objdump, since the first event only initializes the cpu data.

If a trace-on event or any instructions events are synthesized first,
they will consume the limited sample count without ever triggering objdump.
This could result in an empty disassembly output and a false negative
failure from grep.

Additionally, the branch regex lacks 32-bit return instructions like bx
or blx. Previously, larger sample sizes hid this gap. Processing only one
block might guarantee spurious failures on 32-bit systems if the block
ends in an unlisted branch.

>  	grep -q -E ${branch_search} ${file}
>  	echo "Found kernel branches"
>  else

[ ... ]

> @@ -55,9 +55,9 @@ fi
>  
>  ## Test user ##
>  echo "Testing userspace disassembly"
> -perf record -o ${perfdata} -e cs_etm//u -- touch $file > /dev/null 2>&1
> +perf record -o ${perfdata} -e cs_etm//u -Se -m,64K -- touch $file > /dev/null 2>&1
>  perf script -i ${perfdata} -s python:${script_path} -- \
> -	-d --stop-sample=30 2> /dev/null > ${file}
> +	-d --stop-sample=2 2> /dev/null > ${file}

[Severity: Medium]
Are userspace disassembly tests similarly affected by this sample
exhaustion?

Like the kernel test above, reducing the limit to 2 might not process
enough events to trigger objdump if trace-on or instruction events are
encountered first.

>  grep -q -E ${branch_search} ${file}
>  echo "Found userspace branches"

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609-james-cs-context-tracking-fix-v5-0-d53a7d096a19@linaro.org?part=18