tools - perf linux

¿Por qué perf stat muestra "stalled-cycles-backend" como<no compatible>?

Question

Ejecutando perf stat ls muestra esto:

Performance counter stats for ''ls'':

          1.388670 task-clock                #    0.067 CPUs utilized          
                 2 context-switches          #    0.001 M/sec                  
                 0 cpu-migrations            #    0.000 K/sec                  
               266 page-faults               #    0.192 M/sec                  
           3515391 cycles                    #    2.531 GHz                    
           2096636 stalled-cycles-frontend   #   59.64% frontend cycles idle   
   <not supported> stalled-cycles-backend  
           2927468 instructions              #    0.83  insns per cycle        
                                             #    0.72  stalled cycles per insn
            615636 branches                  #  443.328 M/sec                  
             22172 branch-misses             #    3.60% of all branches        

       0.020657192 seconds time elapsed

¿Por qué se muestra stalled-cycles-backend como "no compatible"? ¿Qué tipo de CPU, hardware, kernel o software de espacio de usuario necesito para ver este valor?

Actualmente probé esto en RHEL con Linux 3.12 para x86_64, con la versión "perf" correspondiente, en diferentes sistemas Intel Core i5 e i7 (tipo Ivy Bridge). Ninguno de ellos soporta ciclos paralizados.

Un poco más de información:

$ perf list | grep stalled
  stalled-cycles-frontend OR idle-cycles-frontend    [Hardware event]
  stalled-cycles-frontend OR cpu/stalled-cycles-frontend/ [Kernel PMU event]

$ ls /sys/devices/cpu/events/
branch-instructions  bus-cycles    cache-references  instructions  mem-stores
branch-misses        cache-misses  cpu-cycles        mem-loads     stalled-cycles-frontend

$ cat /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend
event=0x0e,umask=0x01,inv,cmask=0x01

Edición: solo probé esto en una CPU AMD Phenom II X6 1045T, bajo Ubuntu 12.04 con Linux 3.2 (32 bits), y aquí muestra valores tanto para la interfaz de ciclos bloqueados como para la interfaz de ciclos bloqueados.

Answer 1

Acabo de encontrar Re: perf, x86: Agregue partes de la funcionalidad PMU de haswell restante :

> AFAICS backend stall cycles are documented to work on Ivy Bridge.

I''m not aware of any documentation that presents these events
as accurate frontend/backend stalls without using the full
TopDown methology (Optimization manual B.3.2)

Por lo tanto, los contadores de back-end de ciclos paralizados de IIUC no son fiables en Ivy Bridge, y es por eso que los desarrolladores del núcleo han decidido no apoyarlos.

Y por supuesto, Linux '' perf_event_intel.c admite PERF_COUNT_HW_STALLED_CYCLES_BACKEND para Nehalem, Xeon E7 y SandyBridge, pero no para IvyBridge. PERF_COUNT_HW_STALLED_CYCLES_FRONTEND es compatible con IvyBridge, sin embargo.

Así que supongo que no habrá una manera de obtener este contador en mi CPU actual, ya sea cambiar las CPU o usar la metodología completa de arriba a abajo que se menciona en el correo (y que se describe here y http://halobates.de/blog/p/262 )

Answer 2

El perf (o su parte en el kernel) no se actualizó para admitir su CPU, por lo que perf no puede asignar el nombre genérico del evento "stalled-cycles-backend" al evento HW real.

En tal caso, puede ser más fácil encontrar nombres de eventos; por ejemplo, para CPU Intel: del manual de optimización de Intel http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf (que agrupa los eventos por tipo y explica cómo Utilízalos para medir varias partes). No tengo un documento similar para AMD.

Para usar los nombres de eventos con perf sin conversión manual en identificadores de eventos sin procesar (como dice amdn en su answer ), puede usar los scripts de conversión showevtinfo y check_events de perfmon2 ( libpfm4 ; carpeta de ejemplos), tal como se explica en el artículo " Cómo monitorear la totalidad rango de eventos de rendimiento de la CPU "por Bojan Nikolic http://www.bnikolic.co.uk/blog/hpc-prof-events.html . perfmon2 conoce CPUs AMD e Intel, y está escrito en C / C ++

Para las CPU de Intel, la forma más fácil es usar ocperf wrapper sobre perf del proyecto de código abierto de Python de Intel por Andi Kleen "pmu-tools" alojado en github https://github.com/andikleen/pmu-tools e introducido aquí en ML: https://lwn.net/Articles/556983/ y en el blog de Andi http://halobates.de/blog/p/245

El ocperf entiende todos los nombres de eventos de inteligencia del manual de optimización de Intel.

ocperf también apoyará todos los eventos HW con núcleos de linux más antiguos. Tiene su propia base de datos en formato tsv o json con todos los eventos de HW y sus códigos en https://download.01.org/perfmon/ (hay descargador automático en pmu-tools), y la base de datos se actualiza constantemente por Intel empleadores El formato de la base de datos se documenta en el archivo Léame: https://download.01.org/perfmon/readme.txt

Para Sandy Bridge / Ivy Bridge o Haswell, y los kernels 3.10 o más nuevos, también puede usar el script toplev.py de "pmu-tools" para investigar el rendimiento. Aquí está la descripción de su autor, Andi Kleen, http://halobates.de/blog/p/262 " pmu-tools, part II: toplev " basado en el método "TopDown" de Ahmad Yasin " Cómo ajustar las aplicaciones usando un Top -Downización de los problemas de microarquitectura y " análisis descendente. Nunca perdido con contadores de rendimiento "

Answer 3

Parece que el rendimiento no se ha actualizado para comprender todos los eventos de monitoreo de rendimiento que admite Ivy Bridge. Afortunadamente, existe una interfaz genérica, aunque engorrosa, que le permite acceder a la lista completa de eventos de monitoreo de rendimiento. No vi stalled-cycles-backend en la lista cuando le eché un vistazo rápido, pero tal vez lo perdí, o tal vez lo dividieron por todos los diferentes eventos que podrían paralizar el backend.

Empezamos con

perf list --help

... muestra la siguiente NOTA

    1. Intel(R) 64 and IA-32 Architectures Software Developer''s Manual
       Volume 3B: System Programming Guide
       http://www.intel.com/Assets/PDF/manual/253669.pdf

... armado con esa URL terminas en

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3b-part-2-manual.pdf

... quieres la sección 19.3

19.3 EVENTOS DE MONITOREO DE DESEMPEÑO PARA PROCESADORES INTEL® CORE ™ DE 3ª GENERACIÓN Los procesadores Intel® Core ™ de 3ra generación y el procesador Intel Xeon E3-1200 v2 de la familia de productos se basan en el nombre de código de microarquitectura Intel Ivy Bridge. Son compatibles con los eventos de monitoreo de rendimiento arquitectónico enumerados en la Tabla 19-1. Los eventos de monitoreo de rendimiento no arquitectónico en el núcleo del procesador se enumeran en la Tabla 19-5. Los eventos en la Tabla 19-5 se aplican a los procesadores con la firma CPUID de DisplayFamily_DisplayModel que codifica con los siguientes valores: 06_3AH.

... así que para eventos architectural necesitas Tabla 19-1

19.1 EVENTOS DE MONITOREO DE RENDIMIENTO ARQUITECTÓNICO Los eventos de rendimiento arquitectónico se presentan en los procesadores Intel Core Solo e Intel Core Duo. También son compatibles con procesadores basados ​​en la microarquitectura Intel Core. La Tabla 19-1 enumera eventos de rendimiento de arquitectura predefinidos que pueden configurarse usando contadores de rendimiento de propósito general y registros de selección de eventos asociados.

** Tabla 19-1. Eventos de rendimiento arquitectónico

... ahora viene la parte difícil, toma el UMask Value la UMask Value como los 2 dígitos hexadecimales superiores y el número de Event Num son los 2 dígitos hexadecimales más bajos de un número de registro de hardware de 4 dígitos hexadecimales que se le dará a perf stat .

perf stat --help

   -e, --event=
       Select the PMU event. Selection can be a symbolic event name (use
       perf list to list all events) or a raw PMU event (eventsel+umask) in
       the form of rNNN where NNN is a hexadecimal event descriptor.

... dice NNN pero puedes darle NNNN . Verifiquemos que esto funciona, preguntemos a las perf stat de rendimiento las fallas de caché como nombre de evento simbólico y como número hexadecimal de la tabla 19-1. Invocaremos el comando date para simplificar.

$ perf stat -e r412e -e cache-misses date

Fri Mar 28 09:28:52 CDT 2014

Performance counter stats for ''date'':

          2292 r412e                                                       
          2292 cache-misses                                                

   0.003322663 seconds time elapsed

$ 

Como se puede ver, ambos reportaron el mismo número, hasta ahora todo bien. Ahora vamos a la Tabla 19-5 para los registros de hardware no arquitectónicos, de los cuales hay demasiados en la lista aquí, pero enumeraré algunos: