Re: [PATCH] perf tests: Add auto counter reload (ACR) sampling test

["Mi, Dapeng" <dapeng1.mi@linux.intel.com>]

On 4/13/2026 9:26 AM, sashiko-bot@kernel.org 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 <dapeng1.mi@linux.intel.com>
>
> 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.
>