Re: [PATCH] tools/perf/test: Check for perf stat return code in perf all PMU test

Athira Rajeev
2026-04-02T15:46:28Z

> On 2 Apr 2026, at 5:27 AM, Ian Rogers <irogers@google.com> wrote:
>
> On Wed, Apr 1, 2026 at 4:48 PM Namhyung Kim <namhyung@kernel.org> wrote:
>>
>> On Wed, Apr 01, 2026 at 01:40:47PM -0700, Ian Rogers wrote:
>>> This looks like a latent Intel cpu_atom PMU bug. Thomas, wdyt?
>>
>> Are you ok with the change itself then?
>>
>> I'm not sure what's the expectation when the test runs with a regular
>> user. I assume the intention of this change is running as root..
>
> So the test is failing as root on Intel, and the log output is
> extensive. I'd prefer not to have the log output, so we may need to
> work past some known broken items. Otherwise, the change looks okay,
> but there are inconsistencies: `grep -q "<not supported>"` is used in
> the existing code, while `grep -q "not supported"` is used here.
>
> Thanks,
> Ian
>
>> Thanks,
>> Namhyung
>>

Hi Namhyung, Ian

Thanks for trying the change and responding.

Sorry, I missed the comment from Sashiko. Next time I will check explicitly for Sashiko comments too.

The intention of this patch has two things:

1) It was resulting in “false pass” earlier if the test fallback to last check where we run with longer workload. Because error
message contains the event name “$p” and hence matches the “grep” check.

Example:

# ./perf stat -e hv_24x7/CPM_ADJUNCT_PCYC/ ./perf bench internals synthesize
event syntax error: 'hv_24x7/CPM_ADJUNCT_PCYC/'
\___ Bad event or PMU

Unable to find PMU or event on a PMU of ‘hv_24x7'
Run 'perf list' for a list of valid events

Usage: perf stat [<options>] [<command>]

-e, --event <event> event selector. use 'perf list' to list available events
# echo $?
129

Here the test checks for :
<<>>
output=$(perf stat -e "$p" perf bench internals synthesize 2>&1)
if echo "$output" | grep -q "$p”
<<>>

Since the error message contains the event name, it matches grep check and declares test as pass.

To catch this, patch adds a check for “return code”

+ # checked through possible access limitations and permissions.
+ # At this step, non-zero return code from "perf stat" needs to
+ # reported as fail for the user to investigate
+ if [ $stat_result -ne 0 ]
+ then
+ echo "perf stat failed with non-zero return code"
+ err=1
+ continue
+ fi

2) If events are supported in system wide monitoring.

Namhyung is right here that for regular user it will result in fail . I will take care of having check around that.
The reason for using “not supported” text here is:

Example: There is an event in powerpc "vpa_dtl/dtl_all/“ which when run on per thread monitoring:

# ./perf stat -e vpa_dtl/dtl_all/ true
Error:
No supported events found.
Unsupported event (vpa_dtl/dtl_all/H) in per-thread mode, enable system wide with '-a’.

Next running with system wide monitoring:

# ./perf stat -a -e vpa_dtl/dtl_all/ true
Error:
No supported events found.
The sys_perf_event_open() syscall failed for event (vpa_dtl/dtl_all/H): Operation not supported
"dmesg | grep -i perf" may provide additional information.

This is because this event is supported for only “sampling” system wide and not counting.
So patch attempts to use “-a”, if still it fails, we look for “not supported” in logs

Namhyung, Ian,

If the addition of “-a” can cause regression ( like intel one if its not suppose to be run system wide ),
how about adding a case like this:
- Look for "enable system wide with '-a’ “ in the error logs
- If logs matches this message and if user is root, attempt with -a next.
- With “-a”, If the logs has "Operation not supported” , test can continue to next event.

Thanks
Athira