From: sashiko-bot@kernel.org
To: "Dapeng Mi" <dapeng1.mi@linux.intel.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [Patch v10 09/10] perf tests: Add x86 eGPRs/SSP registers sampling test
Date: Tue, 21 Jul 2026 07:42:56 +0000 [thread overview]
Message-ID: <20260721074257.9E1D21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260721072707.3787848-10-dapeng1.mi@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly added validation function `validate_gp_reg_sampling` executes a single-shot pipeline for `perf record`, bypassing the established `perf_record_with_retry` wrapper. This makes the test susceptible to intermittent failures (flakiness) in CI environments and prevents it from utilizing the fast-path optimization.
--
--- Patch [9]: [Patch v10 09/10] perf tests: Add x86 eGPRs/SSP registers sampling test ---
commit a4a8e0ee768722ad01317e4cd04c08a71c39eecf
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
perf tests: Add x86 eGPRs/SSP registers sampling test
Validate that eGPRs (extended general purpose registers) and SSP
(shadow stack pointer) registers can be sampled correctly on x86
platforms with hardware support.
> diff --git a/tools/perf/tests/shell/record.sh b/tools/perf/tests/shell/record.sh
> index 625240809fce3..3c17f68ceb929 100755
> --- a/tools/perf/tests/shell/record.sh
> +++ b/tools/perf/tests/shell/record.sh
[ ... ]
> +validate_gp_reg_sampling() {
> + local regs_opt="$1"
> + local regs_value="$2"
> + local script_field="$3"
> + local sample_output
> + shift 3
> +
> + if ! sample_output=$(perf record -o - "${regs_opt}=${regs_value}" \
> + -e br_inst_retired.near_call -c 1000 --per-thread ${testprog} 2> /dev/null \
> + | perf script -F ip,sym,"${script_field}" -i - 2> /dev/null)
[Severity: Medium]
Will this single-shot pipeline cause intermittent failures in CI environments
under heavy load?
Other tests in this file appear to use the perf_record_with_retry wrapper
to mitigate flakiness. That wrapper provides a fast-path optimization and
scales up the recording duration if the system load prevents sufficient
hardware events from being generated immediately.
Since validate_gp_reg_sampling() executes perf record directly without a retry
loop, could it fail spuriously if the workload doesn't generate enough events
in the initial window?
> + then
> + return 1
> + fi
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721072707.3787848-1-dapeng1.mi@linux.intel.com?part=9
next prev parent reply other threads:[~2026-07-21 7:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 7:26 [Patch v10 00/10] Perf tools: Support eGPRs/SSP/SIMD registers sampling Dapeng Mi
2026-07-21 7:26 ` [Patch v10 01/10] perf dwarf-regs: Fix DWARF register index bounds check Dapeng Mi
2026-07-21 7:26 ` [Patch v10 02/10] perf util: Add missed fields in _attr__fprintf() and __attr_swap() Dapeng Mi
2026-07-21 7:27 ` [Patch v10 03/10] tools headers: Sync x86 headers with kernel sources Dapeng Mi
2026-07-21 7:39 ` sashiko-bot
2026-07-22 1:07 ` Mi, Dapeng
2026-07-21 7:27 ` [Patch v10 04/10] perf headers: Sync perf_event.h/perf_regs.h with the kernel headers Dapeng Mi
2026-07-21 7:47 ` sashiko-bot
2026-07-22 1:27 ` Mi, Dapeng
2026-07-21 7:27 ` [Patch v10 05/10] perf regs: Support x86 eGPRs/SSP sampling Dapeng Mi
2026-07-21 7:52 ` sashiko-bot
2026-07-22 2:09 ` Mi, Dapeng
2026-07-21 7:27 ` [Patch v10 06/10] perf regs: Support x86 SIMD registers sampling Dapeng Mi
2026-07-21 7:50 ` sashiko-bot
2026-07-22 2:31 ` Mi, Dapeng
2026-07-21 7:27 ` [Patch v10 07/10] perf regs: Enable dumping of SIMD registers Dapeng Mi
2026-07-21 7:27 ` [Patch v10 08/10] perf dwarf-regs: Add SIMD/eGPRs support for x86 DWARF registers Dapeng Mi
2026-07-21 7:27 ` [Patch v10 09/10] perf tests: Add x86 eGPRs/SSP registers sampling test Dapeng Mi
2026-07-21 7:42 ` sashiko-bot [this message]
2026-07-22 2:42 ` Mi, Dapeng
2026-07-21 7:27 ` [Patch v10 10/10] perf tests: Add SIMD " Dapeng Mi
2026-07-21 7:48 ` sashiko-bot
2026-07-22 2:43 ` Mi, Dapeng
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=20260721074257.9E1D21F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dapeng1.mi@linux.intel.com \
--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