From: sashiko-bot@kernel.org
To: "James Clark" <james.clark@linaro.org>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v4 18/19] perf test cs-etm: Speed up disassembly test
Date: Tue, 09 Jun 2026 15:06:55 +0000 [thread overview]
Message-ID: <20260609150656.3CECD1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260609-james-cs-context-tracking-fix-v4-18-44f9fb9e5c42@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Reducing `--stop-sample` to 2 causes the disassembly tests to spuriously fail on multi-core systems because the Python decoder limits the raw number of decoded events rather than objdump calls.
--
commit 4c3c2bcace55cfb656bbb5453c90886308b6f40e
Author: James Clark <james.clark@linaro.org>
perf test cs-etm: Speed up disassembly test
This commit speeds up the coresight disassembly tests by using exit
snapshots to limit the amount of trace decoded, and by reducing the
stop-sample limit from 30 to 2 for both kernel and userspace testing.
> 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 reduced sample limit cause spurious test failures on multi-core
systems?
The Python decoder (arm-cs-trace-disasm.py) increments a global index for
every processed event, regardless of CPU. Printing disassembly for a single
basic block requires at least two events from the same CPU (one to
initialize the address cache, the next to construct the range and call
print_disam()).
With events interleaved across CPUs, and cs_etm synthesizing both
instructions and branches, could the 3-event limit (indexes 0, 1, 2) be
exhausted by cache initializations or non-branch events before a single
print_disam() call occurs? If the script exits before generating any
disassembly, the grep check below would fail.
> 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]
Similarly for the userspace test, is there a risk of the script exiting
before generating any disassembly if non-branch events or interleaved CPU
events consume the strict limit of 2?
> grep -q -E ${branch_search} ${file}
> echo "Found userspace branches"
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260609-james-cs-context-tracking-fix-v4-0-44f9fb9e5c42@linaro.org?part=18
next prev parent reply other threads:[~2026-06-09 15:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-09 14:30 [PATCH v4 00/19] perf cs-etm: Queue context packets for frontend James Clark
2026-06-09 14:30 ` [PATCH v4 01/19] " James Clark
2026-06-09 14:46 ` sashiko-bot
2026-06-09 14:30 ` [PATCH v4 02/19] perf test: Add workload-ctl option James Clark
2026-06-09 14:40 ` sashiko-bot
2026-06-09 14:30 ` [PATCH v4 03/19] perf test: Add a workload that forces context switches James Clark
2026-06-09 14:30 ` [PATCH v4 04/19] perf test cs-etm: Test process attribution James Clark
2026-06-09 14:41 ` sashiko-bot
2026-06-09 14:30 ` [PATCH v4 05/19] perf test: Add deterministic workload James Clark
2026-06-09 14:30 ` [PATCH v4 06/19] perf test cs-etm: Replace unroll loop thread with deterministic decode test James Clark
2026-06-09 14:52 ` sashiko-bot
2026-06-09 14:31 ` [PATCH v4 07/19] perf test cs-etm: Remove asm_pure_loop test James Clark
2026-06-09 14:53 ` sashiko-bot
2026-06-09 14:31 ` [PATCH v4 08/19] perf test cs-etm: Replace memcpy test with raw dump stress test James Clark
2026-06-09 14:31 ` [PATCH v4 09/19] perf test: Add named_threads workload James Clark
2026-06-09 14:50 ` sashiko-bot
2026-06-09 14:31 ` [PATCH v4 10/19] perf test cs-etm: Test decoding for concurrent threads test James Clark
2026-06-09 14:31 ` [PATCH v4 11/19] perf test cs-etm: Remove duplicate branch tests James Clark
2026-06-09 14:31 ` [PATCH v4 12/19] perf test cs-etm: Skip if not root James Clark
2026-06-09 14:53 ` sashiko-bot
2026-06-09 14:31 ` [PATCH v4 13/19] perf test cs-etm: Reduce snapshot size James Clark
2026-06-09 14:31 ` [PATCH v4 14/19] perf test cs-etm: Speed up basic test James Clark
2026-06-09 14:31 ` [PATCH v4 15/19] perf test cs-etm: Remove unused Coresight workloads James Clark
2026-06-09 14:31 ` [PATCH v4 16/19] perf test cs-etm: Make disassembly test use kcore James Clark
2026-06-09 14:31 ` [PATCH v4 17/19] perf test cs-etm: Add all branch instructions to test James Clark
2026-06-09 14:31 ` [PATCH v4 18/19] perf test cs-etm: Speed up disassembly test James Clark
2026-06-09 15:06 ` sashiko-bot [this message]
2026-06-09 14:31 ` [PATCH v4 19/19] perf test cs-etm: Move existing tests to coresight folder James Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260609150656.3CECD1F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=james.clark@linaro.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox