Perf_Event_Open Always Returns -1

perf_event_open always returns -1

From the lack of anything relevant in dmesg and sysfs, it should hopefully now be apparent that the PMU isn't being described to the kernel. Thus perf events doesn't know anything about the hardware event you're asking for, so it's little surprise that it fails to open it. What you need to do is make sure the kernel does know about the PMU, so that the driver picks it up - said driver should already be built-in via CONFIG_HW_PERF_EVENTS, which is on by default with CONFIG_PERF_EVENTS and doesn't look to be disabled in your config, but it might be worth double-checking.

It looks like the PMU is described in the devicetree in their 3.18 kernel, so my best guess is that your board might be booting using the legacy boardfile rather than FDT. I don't know much about Raspberry Pi specifics, but judging by this fairly exhaustive article (I'd say skip directly to section 3.1), it seems relatively straightforward to reconfigure the bootloader to use FDT.

Permission denied on perf_event_open, is there another way than to use sudo or changing the perf_event_paranoid file?

The RETURN VALUE section of the Linux perf_event_open() system call states in part:

   ...

   EACCES Returned when the requested event requires CAP_PERFMON
          (since Linux 5.8) or CAP_SYS_ADMIN permissions (or a more
          permissive perf_event paranoid setting).  Some common
          cases where an unprivileged process may encounter this
          error: attaching to a process owned by a different user;
          monitoring all processes on a given CPU (i.e., specifying
          the pid argument as -1); and not setting exclude_kernel
          when the paranoid setting requires it.

   ...

   EPERM  Returned on many (but not all) architectures when an
          unsupported exclude_hv, exclude_idle, exclude_user, or
          exclude_kernel setting is specified.

          It can also happen, as with EACCES, when the requested
          event requires CAP_PERFMON (since Linux 5.8) or
          CAP_SYS_ADMIN permissions (or a more permissive perf_event
          paranoid setting).  This includes setting a breakpoint on
          a kernel address, and (since Linux 3.13) setting a kernel
          function-trace tracepoint.

From the example code posted, the values pe.exclude_kernel = 0; or pe.exclude_hv = 0; are likely causing permission issues given your statement about the paranoid setting.

I read the counter's value with perf on linux,the value of it is always be 0

I just tried your code and removing following lines (line no 75,76) makes the code work for me.

attr.read_format = PERF_FORMAT_TOTAL_TIME_ENABLED |
                   PERF_FORMAT_TOTAL_TIME_RUNNING;

---

Related Topics