Re: [PATCH v2 17/18] 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] Limiting the disassembly test to `--stop-sample=2` makes the test highly flaky, as early trace blocks split by exceptions will contain no branch instructions.
--

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

perf test cs-etm: Speed up disassembly test

This commit attempts to speed up the disassembly test by using exit snapshots
and limiting the perf script output to 2 samples instead of 30. This avoids
expensive objdump calls, particularly when using kcore.

> diff --git a/tools/perf/tests/shell/test_arm_coresight_disasm.sh b/tools/perf/tests/shell/test_arm_coresight_disasm.sh
> --- 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 [ -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]
Could this tight limit cause the test to become flaky?

By reducing --stop-sample to 2, the Python script processes exactly 3 events
before exiting. The first event is usually a Trace On discontinuity packet
which produces no disassembly.

If the following trace block is interrupted by a kernel interrupt before a
branch instruction occurs, the decoded block won't contain any branches. The
third event would just be another Trace On packet, and the script would exit
having produced an output file with zero branch instructions.

Since the test script runs with set -e, wouldn't the subsequent grep fail
and trigger a false positive test failure?

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

[ ... ]

> @@ -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]
Similarly, does this risk introducing flakiness in the userspace testing due
to early page faults?

As with the kernel trace, if early userspace execution hits a page fault in
ld.so or another exception before taking a branch, the limited events
processed won't include any branch disassembly.

Would slightly increasing the stop-sample limit avoid these intermittent
early execution trace interruptions while still remaining faster than 30?

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

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602-james-cs-context-tracking-fix-v2-0-85b5ce6f55c6@linaro.org?part=17