Re: [PATCH] perf tests: Add auto counter reload (ACR) sampling test
"Mi, Dapeng" <[email protected]>
| Newsgroups | dev.linux.lists.sashiko,org.kernel.vger.linux-perf-users |
|---|---|
| Message-ID | <[email protected]> |
On 4/13/2026 9:26 AM, [email protected] wrote: > Sashiko AI review found 1 potential issue(s): > - [Medium] The test fails to genuinely verify that self-reloaded events do not generate records because the chosen sample periods and workload ensure the self-reloaded event never actually overflows. > -- > > commit 5e7a7e069f4c078327e3d8166d7f74d9084ec8a4 > Author: Dapeng Mi <[email protected]> > > perf tests: Add auto counter reload (ACR) sampling test > > This commit adds an auto counter reload sampling test to verify that the > intended event records can be captured and self-reloaded events do not > generate any records. > >> diff --git a/tools/perf/tests/shell/record.sh b/tools/perf/tests/shell/record.sh >> index 7cb81cf3444a7..1068843282f51 100755 >> --- a/tools/perf/tests/shell/record.sh >> +++ b/tools/perf/tests/shell/record.sh > [ ... ] >> @@ -402,6 +402,47 @@ test_callgraph() { >> echo "Callgraph test [Success]" >> } >> >> +test_acr_sampling() { >> + events="{instructions/period=20000,acr_mask=0x2/u,cycles/period=40000,acr_mask=0x3/u}" >> + pebs_events="{instructions/period=20000,acr_mask=0x2/pu,cycles/period=40000,acr_mask=0x3/u}" > Does this test configuration actually verify that self-reloaded events do not > generate records? > > The test runs the thloop workload, which is a tight CPU loop with an inherently > high IPC (typically > 0.5). With periods of 20000 for instructions and 40000 > for cycles, the instructions event will always overflow first. Hmm, makes sense. I would check the IPC of the thloop workload. Suppose setting periods of both instructions and cycles to 20000 (IPC=1) could be a better choice. Thanks. > > When the instructions event overflows, its acr_mask=0x2 triggers an auto-reload > of the cycles counter, resetting its progress toward overflow. > > Because it is continually reset by the instructions event before reaching > 40000, the cycles counter never overflows. > > The test asserts that no records are generated for cycles and passes, but is > this simply because the event never fired rather than due to self-reloaded PMI > suppression working correctly? > > If the hardware PMI suppression for self-reloaded events was broken, wouldn't > this test still pass? > > Additionally, if the test ran on a system with IPC < 0.5, wouldn't the cycles > event overflow first, resetting both itself and instructions (acr_mask=0x3)? > This would prevent instructions from generating a record, causing the test > to fail. >