perf_event_open всегда возвращает -1

Я запускаю следующую программу, которая вызывает системный вызов perf_event_open: Linux sama-desktop 3.18.0-20-rpi2 # 21-Ubuntu SMP PREEMPT Sun 5 апреля 01:56:02 UTC 2015 armv7l armv7l armv7l GNU / Linux

Программа:

#define _GNU_SOURCE 1

#include <asm/unistd.h>
#include <fcntl.h>
#include <linux/perf_event.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

long perf_event_open(struct perf_event_attr* event_attr, pid_t pid, int cpu, int group_fd, unsigned long flags)
{
    return syscall(__NR_perf_event_open, event_attr, pid, cpu, group_fd, flags);
}

static void perf_event_handler(int signum, siginfo_t* info, void* ucontext) {
    if(info->si_code != POLL_HUP) {
        // Only POLL_HUP should happen.
        exit(EXIT_FAILURE);
    }

    ioctl(info->si_fd, PERF_EVENT_IOC_REFRESH, 1);
}

int main(int argc, char** argv)
{
    // Configure signal handler
    struct sigaction sa;
    memset(&sa, 0, sizeof(struct sigaction));
    sa.sa_sigaction = perf_event_handler;
    sa.sa_flags = SA_SIGINFO;

    // Setup signal handler
    if (sigaction(SIGIO, &sa, NULL) < 0) {
        fprintf(stderr,"Error setting up signal handler\n");
        perror("sigaction");
        exit(EXIT_FAILURE);
    }

    // Configure perf_event_attr struct
    struct perf_event_attr pe;
    memset(&pe, 0, sizeof(struct perf_event_attr));
    pe.type = PERF_TYPE_HARDWARE;
    pe.size = sizeof(struct perf_event_attr);
    pe.config = PERF_COUNT_HW_INSTRUCTIONS;     // Count retired hardware instructions
    pe.disabled = 1;        // Event is initially disabled
    pe.sample_type = PERF_SAMPLE_IP;
    pe.sample_period = 1000;
    pe.exclude_kernel = 1;  // excluding events that happen in the kernel-space
    pe.exclude_hv = 1;      // excluding events that happen in the hypervisor

    pid_t pid = 0;  // measure the current process/thread
    int cpu = -1;   // measure on any cpu
    int group_fd = -1;
    unsigned long flags = 0;

    int fd = perf_event_open(&pe, pid, cpu, group_fd, flags);
    if (fd == -1) {
        fprintf(stderr, "Error opening leader %llx\n", pe.config);
        perror("perf_event_open");
        exit(EXIT_FAILURE);
    }
    // Setup event handler for overflow signals
    fcntl(fd, F_SETFL, O_NONBLOCK|O_ASYNC);
    fcntl(fd, F_SETSIG, SIGIO);
    fcntl(fd, F_SETOWN, getpid());

    ioctl(fd, PERF_EVENT_IOC_RESET, 0);     // Reset event counter to 0
    ioctl(fd, PERF_EVENT_IOC_REFRESH, 1);   // 

// Start monitoring

    long loopCount = 1000000;
    long c = 0;
    long i = 0;

    // Some sample payload.
    for(i = 0; i < loopCount; i++) {
        c += 1;
    }

// End monitoring

    ioctl(fd, PERF_EVENT_IOC_DISABLE, 0);   // Disable event

    long long counter;
    read(fd, &counter, sizeof(long long));  // Read event counter value

    printf("Used %lld instructions\n", counter);

    close(fd);
}

который возвращает ошибку открытия лидера. Я проверил fd, и похоже, что он всегда возвращает -1.

Я использовал второй пример из руководства по системным вызовам perf, который имеет ту же проблему (ошибка открытия лидера, вызванного fd = -1). Вот пример кода для перфоманса в руководстве:

  #include <stdlib.h>
   #include <stdio.h>
   #include <unistd.h>
   #include <string.h>
   #include <sys/ioctl.h>
   #include <linux/perf_event.h>
   #include <asm/unistd.h>

   static long
   perf_event_open(struct perf_event_attr *hw_event, pid_t pid,
                   int cpu, int group_fd, unsigned long flags)
   {
       int ret;

       ret = syscall(__NR_perf_event_open, hw_event, pid, cpu,
                      group_fd, flags);
       return ret;
   }

   int
   main(int argc, char **argv)
   {
       struct perf_event_attr pe;
       long long count;
       int fd;

       memset(&pe, 0, sizeof(struct perf_event_attr));
       pe.type = PERF_TYPE_HARDWARE;
       pe.size = sizeof(struct perf_event_attr);
       pe.config = PERF_COUNT_HW_INSTRUCTIONS;
       pe.disabled = 1;
       pe.exclude_kernel = 1;
       pe.exclude_hv = 1;

       fd = perf_event_open(&pe, 0, -1, -1, 0);
       if (fd == -1) {
          fprintf(stderr, "Error opening leader %llx\n", pe.config);
          exit(EXIT_FAILURE);
       }

       ioctl(fd, PERF_EVENT_IOC_RESET, 0);
       ioctl(fd, PERF_EVENT_IOC_ENABLE, 0);

       printf("Measuring instruction count for this printf\n");

       ioctl(fd, PERF_EVENT_IOC_DISABLE, 0);
       read(fd, &count, sizeof(long long));

       printf("Used %lld instructions\n", count);

       close(fd);
   }

Я также сделал свой собственный код, чтобы просто проверить, нет ли у perf проблем с доступом к регистрам PMU. Поэтому я сделал модуль ядра, чтобы разрешить доступ в пользовательском режиме к регистрам PMU.

в режиме ядра выполняются только следующие действия:

    asm volatile("mrc p15, 0, %0, c9, c14, 0" :: "r"(1));
    asm volatile("mcr p15, 0, %0, c9, c14, 0" :: "r"(1));

а затем я попытался запустить perf_event_open

init(void)
{
        static struct perf_event_attr attr;
        attr.type = PERF_TYPE_HARDWARE;
//      attr.config = PERF_COUNT_HW_INSTRUCTIONS;
        attr.config = PERF_COUNT_HW_CPU_CYCLES;
        fddev = syscall(__NR_perf_event_open, &attr, 0, -1, -1, 0);
        printf("The fddev value is %d", fddev);
}

который возвращает -1. Я также использовал это репо, которое снова возвращает -1.

Я также посмотрел на kallsyms, чтобы убедиться, что там есть системный вызов perf_event_open.

root@sama-desktop:/home/sama# cat /proc/kallsyms | grep "perf_event_open"
800f3178 T SyS_perf_event_open
800f3178 T sys_perf_event_open

и вот результат /boot/config-3.18.0-20-rpi2:

# 
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_SYSTEM_TRUSTED_KEYRING is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_OPROFILE=m
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_JUMP_LABEL=y
CONFIG_UPROBES=y
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
CONFIG_CC_STACKPROTECTOR_REGULAR=y
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

а вот вывод dmesg:

root@sama-desktop:/boot# dmesg | grep "perf"
[    0.003891] Initializing cgroup subsys perf_event

и вот результат для дерева устройств:

root@sama-desktop:# ls -la /sys/bus/event_source/devices
total 0
drwxr-xr-x 2 root root 0 jul 18 20:15 .
drwxr-xr-x 4 root root 0 jan  1  1970 ..
lrwxrwxrwx 1 root root 0 jan  1  1970 breakpoint -> ../../../devices/breakpoint
lrwxrwxrwx 1 root root 0 jan  1  1970 software -> ../../../devices/software
lrwxrwxrwx 1 root root 0 jan  1  1970 tracepoint -> ../../../devices/tracepoint

Я действительно не знаю, почему perf_event_open возвращает -1.


person Sama Azari    schedule 18.07.2016    source источник
comment
У вас есть PMU, описанные в вашем дереве устройств? Вы видите что-то вроде hw perfevents: enabled with xxx PMU driver, x counters available довольно рано в dmesg?   -  person Notlikethat    schedule 18.07.2016
comment
Нет, я этого не вижу. Однако я написал свой собственный драйвер, чтобы разрешить доступ к PMU из используемого режима. Также я использовал драйвер этого репозитория (https://github.com/gotitpolice/enable_arm_pmu), который снова включает PMU для пользователя а затем использует perf. Обновил вопрос с выводом dmesg.   -  person Sama Azari    schedule 18.07.2016
comment
У меня были проблемы с perf_event_open() работой на моем рабочем столе x86_64 - моя проблема оказалась в том, что мой рабочий стол Linux работал на виртуальной машине (VMware). Я публикую этот комментарий, потому что, когда у меня были проблемы с perf_event_open(), этот вопрос был самым близким к проблеме, с которой я столкнулся, и я полагаю, что здесь может оказаться кто-то другой с аналогичной проблемой.   -  person Michael Burr    schedule 30.01.2018


Ответы (3)


Из-за отсутствия чего-либо значимого в dmesg и sysfs теперь должно быть очевидно, что PMU не описывается ядру. Таким образом, perf events ничего не знает о запрашиваемом вами аппаратном событии, поэтому неудивительно, что ему не удается его открыть. Что вам нужно сделать, так это убедиться, что ядро ​​знает о PMU, чтобы драйвер подхватил его - указанный драйвер уже должен быть встроен через CONFIG_HW_PERF_EVENTS, который по умолчанию включен с CONFIG_PERF_EVENTS и не выглядит отключенным в вашей конфигурации, но, возможно, стоит перепроверить.

Похоже, PMU описан в дереве устройств в их ядре 3.18, поэтому я предполагаю, что ваша плата может загружаться с использованием устаревшего файла платы, а не FDT. Я не очень разбираюсь в особенностях Raspberry Pi, но, судя по этой довольно исчерпывающей статье (я бы сказал, сразу перейти к разделу 3.1), кажется относительно простым перенастроить загрузчик для использования FDT.

person Notlikethat    schedule 18.07.2016

Для всех, кто задается этим вопросом со сборкой Yocto i.MX6, такой как моя, но в отличие от OP имеет что-то вроде этого в dmesg:

hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available

Попробуйте закомментировать эти две строки в примере кода:

pe.exclude_kernel = 1;
pe.exclude_hv = 1;

Для меня это сделало вызов perf_event_open успешным, и я смог собрать данные.

person Jeff Trull    schedule 28.05.2017

У меня была такая же проблема с вами, и теперь моя проблема заключается в разрешении программы, вы должны использовать более высокое разрешение для ее запуска, чтобы все было в порядке. Использую sudo ./a.out, и тогда все нормально. Может и поможет.

person sharix    schedule 02.12.2017