Warum zeigt Perf Stat "blockierte Zyklen-Backend" als <nicht unterstützt> an?

Question

perf stat ls Lauf zeigt dies:

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 

Warum ist ins Stocken geraten-Zyklen-Backend gezeigt als "nicht unterstützt"? Welche Art von CPU-, Hardware-, Kernel- oder User-Space-Software benötige ich, um diesen Wert zu sehen?

Derzeit versucht RHEL mit Linux 3.12 für x86_64, mit passender "perf" -Version, auf verschiedenen Intel Core i5 und i7-Systemen (Ivy-Bridge-Typ). Keiner von ihnen unterstützt blockierte Zyklen-Backend.

Einige weitere Informationen:

$ 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 

Edit: habe gerade versucht, diese auf einem AMD Phenom II X6 1045T CPU unter Ubuntu 12.04 mit Linux 3.2 (32 Bit) - und hier zeigt es Werte für beide ins Stocken geraten -cycles-frontend und stalled-cycles-backend.

Answer 1

Es sieht so aus, als ob perf nicht aktualisiert wurde, um alle Leistungsüberwachungsereignisse zu verstehen, die Ivy Bridge unterstützt. Glücklicherweise gibt es eine generische, wenn auch umständliche Schnittstelle, mit der Sie auf die vollständige Liste der Leistungsüberwachungsereignisse zugreifen können. Ich habe in der Liste nicht gesehen, wenn ich es kurz angeschaut habe, aber vielleicht habe ich es verpasst, oder vielleicht haben sie es durch die verschiedenen Ereignisse, die das Backend blockieren könnten, durchbrochen.

Wir mit

perf list --help 

starten ... zeigt folgende HINWEIS

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 

... bewaffnet mit dieser URL Sie am Ende in

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

.. .Sie wollen Abschnitt 19.3

19,3 PERFORMANCE MONITORING VERANSTALTUNGEN FÜR 3RD GENERATION Intel® Core ™ Prozessoren 3. Generation der Intel® Core ™ Prozessoren und Intel Xeon Prozessor E3-1200 v2-Produktfamilie basieren auf Intel-Mikroarchitektur Codenamen Ivy Bridge. Sie unterstützen Ereignisse zur Überwachung der Architekturleistung, die in Tabelle 19-1 aufgeführt sind. Nicht-architektonische Leistungsüberwachungsereignisse im Prozessorkern sind in Tabelle 19-5 aufgeführt. Die Ereignisse in Tabelle 19-5 gelten für Prozessoren mit CPUID-Signatur der DisplayFamily_DisplayModel-Codierung mit den folgenden Werten: 06_3AH.

... so für architectural Ereignisse müssen Sie Tabelle 19-1

19,1 ARCHITEKTUR PERFORMANCE-MONITORING EVENTS Architektur Performance-Events werden in Intel Core Solo und Intel Core Duo-Prozessoren eingeführt. Sie werden auch auf Prozessoren mit Intel Core-Mikroarchitektur unterstützt. Tabelle 19-1 listet vordefinierte Leistungsereignisse für die Architektur auf, die mit allgemeinen Leistungsindikatoren und zugeordneten Ereignisauswahlregistern konfiguriert werden können.

** Tabelle 19-1.Architektonische Performance-Events

... jetzt kommt der schwierige Teil, nehmen Sie die UMask Value als die oberen 2 Hex-Ziffern und die Event Num ist die unteren zwei hexadezimalen Ziffern eines 4 Hex-Ziffern-Hardware-Registernummer, die an perf stat zu vergeben ist.

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. 

... sagt es NNN aber man kann es NNNN geben. Lassen Sie uns überprüfen, ob dies funktioniert. Lassen Sie uns perf stat nach Cache-Fehlern fragen, sowohl als symbolischer Ereignisname als auch als Hexadezimalzahl aus Tabelle 19-1. Wir rufen den Befehl date zur Vereinfachung auf.

$ 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 

$ 

Wie Sie sehen können beide die gleiche Nummer gemeldet, so weit so gut. Nun gehen wir in Tabelle 19-5 für die nicht-architektonischen Hardware-Register, von denen es zu viele sind auch hier aufzulisten, aber ich werde eine Liste paar:

Answer 2

Gerade Re: perf, x86: Add parts of the remaining haswell PMU functionality gefunden:

> 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) 

Also IIUC blockiert-Zyklen-Backend-Zähler sind auf Ivy Bridge zu unzuverlässig, und deshalb haben die Kernel-Entwickler beschlossen, sie nicht zu unterstützen.

Und tatsächlich unterstützt Linux 'perf_event_intel.cPERF_COUNT_HW_STALLED_CYCLES_BACKEND für Nehalem, Xeon E7 und SandyBridge, aber nicht für IvyBridge. PERF_COUNT_HW_STALLED_CYCLES_FRONTEND wird jedoch für IvyBridge unterstützt.

Also ich denke, es wird keine Möglichkeit, diesen Zähler auf meinem aktuellen CPU zu erhalten - entweder Schalter CPUs oder verwenden Sie die vollständige Top-down-Methode in der Mail genannte (und beschrieben here und here)

Answer 3

Die perf (oder der Kernel-Teil) wurde nicht aktualisiert, um Ihre CPU zu unterstützen, daher kann Perf den generischen Ereignisnamen "stalled-cycles-backend" nicht dem tatsächlichen HW-Ereignis zuordnen.

In diesem Fall kann es einfacher sein, Ereignisnamen zu finden; z.B. für Intel CPUs - aus dem Intel Optimierungshandbuch http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf (das Ereignisse nach Typ gruppiert und erklärt, wie man sie verwendet, um verschiedene Teile zu messen). Habe kein ähnliches Dokument für AMD.

Um Ereignisnamen mit perf ohne manuelle Konvertierung in rohen Ereignis-IDs (wie amdn sagt in seinem answer) können Sie Konverter Skripte showevtinfo und check_events von perfmon2 zu verwenden (libpfm4; Beispielen Ordner) ein, wie in dem Artikel "So überwachen Sie den vollen Bereich der CPU-Leistungsereignisse "von Bojan Nikolic http://www.bnikolic.co.uk/blog/hpc-prof-events.html.perfmon2 kennt AMD und Intel-CPUs, und in C/C++

Für Intel-CPUs der einfachste Weg, geschrieben ocperf Wrapper über perf von Intel Open-Source-Python-Projekt von Andi Kleen "PMU-tools" bei Github gehostet verwenden https://github.com/andikleen/pmu-tools und hier in ML vorgestellt: https://lwn.net/Articles/556983/ und in Andi's Blog http://halobates.de/blog/p/245

Die ocperf versteht alle Intel Event-Namen aus Intels Optimierungshandbuch.

ocperf unterstützt auch jedes HW-Ereignis mit älteren Linux-Kerneln. Es hat eine eigene Datenbank im TSV- oder JSON-Format mit allen HW-Ereignissen und deren Codes unter https://download.01.org/perfmon/ (es gibt Auto-Downloader in pmu-tools), und die Datenbank wird ständig von Intels Arbeitgebern aktualisiert. Format der Datenbank wird in readme dokumentiert: https://download.01.org/perfmon/readme.txt

Für Sandy Bridge/Ivy Bridge oder Haswell und Kernel 3.10 oder höher, können Sie auch toplev.py Skript von "PMU-Tools" verwenden können, die Leistung zu untersuchen. Hier ist die Beschreibung von seinem Autor, Andi Kleen, http://halobates.de/blog/p/262 "PMU-Tool, Teil II: Toplev" basierend auf "TopDown" -Methode von Ahmad Yasin "How to Tune Applications Using a Top-Down Characterization of Microarchitectural Issues und "Top Down Analysis. Never lost with performance counters"