Was sind Stalled-Cycles-Frontend und Stalled-Cycles-Backend im Ergebnis 'Perf Stat'?

Weiß jemand, was die Bedeutung von Blocked-Cycle-Frontend und Stalled-Cycle-Backend im Perf-Stat-Ergebnis bedeutet? Ich habe im Internet gesucht, aber keine Antwort gefunden. Vielen Dank

$ sudo perf stat ls                     

Performance counter stats for 'ls':

      0.602144 task-clock                #    0.762 CPUs utilized          
             0 context-switches          #    0.000 K/sec                  
             0 CPU-migrations            #    0.000 K/sec                  
           236 page-faults               #    0.392 M/sec                  
        768956 cycles                    #    1.277 GHz                    
        962999 stalled-cycles-frontend   #  125.23% frontend cycles idle   
        634360 stalled-cycles-backend    #   82.50% backend  cycles idle
        890060 instructions              #    1.16  insns per cycle        
                                         #    1.08  stalled cycles per insn
        179378 branches                  #  297.899 M/sec                  
          9362 branch-misses             #    5.22% of all branches         [48.33%]

   0.000790562 seconds time elapsed

Die Theorie:

Beginnen wir damit: Heutzutage sind die CPUs superskalar, was bedeutet, dass sie mehr als einen Befehl pro Zyklus (IPC) ausführen können. Neueste Intel-Architekturen können bis zu 4 IPC (4 x86-Befehlsdecoder) verwenden. Lassen Sie uns die Makro- / Mikrofusion nicht zur Diskussion stellen, um die Dinge noch komplizierter zu machen :).

In der Regel erreichen Workloads aufgrund verschiedener Ressourcenkonflikte nicht IPC = 4. Dies bedeutet, dass die CPU Zyklen verschwendet (die Anzahl der Anweisungen wird von der Software gegeben und die CPU muss sie in so wenigen Zyklen wie möglich ausführen).

Wir können die von der CPU verbrauchten Gesamtzyklen in drei Kategorien einteilen:

1. Zyklen, in denen Anweisungen eingestellt werden (nützliche Arbeit)
2. Zyklen, die im Back-End verbracht werden (verschwendet)
3. Zyklen im Front-End (verschwendet).

Um einen IPC von 4 zu erhalten, muss die Anzahl der auslaufenden Zyklen nahe an der Gesamtzahl der Zyklen liegen. Beachten Sie, dass in dieser Phase alle Mikrooperationen (uOps) aus der Pipeline ausscheiden und ihre Ergebnisse in Register / Caches übertragen. Zu diesem Zeitpunkt können sogar mehr als 4 uOps in den Ruhestand gehen, da diese Anzahl durch die Anzahl der Ausführungsports angegeben wird. Wenn Sie nur 25% der Zyklen haben, die 4 uOps ausfallen, haben Sie einen Gesamt-IPC von 1.

Die im Back-End blockierten Zyklen sind eine Verschwendung, da die CPU auf Ressourcen (normalerweise Speicher) warten oder Anweisungen mit langer Latenz (z. B. Transcedentals - sqrt, reziproke, Divisionen usw.) beenden muss.

Die im Front-End blockierten Zyklen sind eine Verschwendung, da das Front-End das Back-End nicht mit Mikrooperationen versorgt. Dies kann bedeuten, dass Sie Fehler im Anweisungscache haben oder komplexe Anweisungen, die nicht bereits im Mikrooperationscache dekodiert sind. Just-in-Time-kompilierter Code drückt dieses Verhalten normalerweise aus.

Ein weiterer Grund für das Abwürgen ist das Fehlen einer Verzweigungsvorhersage. Das nennt man schlechte Spekulation. In diesem Fall werden uOps ausgegeben, aber verworfen, weil der BP falsch vorhergesagt hat.

Die Implementierung in Profilern:

Wie interpretieren Sie die blockierten BE- und FE-Zyklen?

Unterschiedliche Profiler haben unterschiedliche Ansätze für diese Metriken. In vTune addieren sich die Kategorien 1 bis 3 zu 100% der Zyklen. Das ist vernünftig, weil entweder Ihre CPU blockiert ist (keine uOps gehen in den Ruhestand) oder nützliche Arbeit (uOps) in den Ruhestand geht. Weitere Informationen finden Sie hier: https://software.intel.com/sites/products/documentation/doclib/stdxe/2013SP1/amplifierxe/snb/index.htm

In der Perfektion passiert dies normalerweise nicht. Das ist ein Problem, denn wenn 125% der Zyklen im Frontend stehen bleiben , wissen Sie nicht, wie Sie das wirklich interpretieren sollen. Sie könnten die Metrik> 1 mit der Tatsache verknüpfen, dass es 4 Decoder gibt. Wenn Sie jedoch die Argumentation fortsetzen, stimmt der IPC nicht überein.

Noch besser, Sie wissen nicht, wie groß das Problem ist. 125% von was? Was bedeuten die #Zyklen dann?

Ich persönlich sehe ein bisschen misstrauisch gegenüber den BE- und FE-Zyklen von perf aus und hoffe, dass dies behoben wird.

Wahrscheinlich erhalten wir die endgültige Antwort, indem wir den Code von hier aus debuggen: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/builtin-stat.c

So konvertieren Sie generische Ereignisse, die von perf exportiert wurden, in Rohereignisse Ihrer CPU-Dokumentation, die Sie ausführen können:

more /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend 

Es wird dir so etwas zeigen

event=0x0e,umask=0x01,inv,cmask=0x01

Laut der Intel-Dokumentation SDM Volume 3B (ich habe einen Core i5-2520):

UOPS_ISSUED.ANY:

• Erhöht in jedem Zyklus die Anzahl der von der RAT an RS ausgegebenen Uops.
• Setzen Sie Cmask = 1, Inv = 1, Any = 1, um blockierte Zyklen dieses Kerns zu zählen.

Für das Blocked-Cycles-Backend-Ereignis, das auf meinem System in event = 0xb1, umask = 0x01 übersetzt wird, heißt es in derselben Dokumentation:

UOPS_DISPATCHED.THREAD:

• Zählt die Gesamtzahl der Uops, die pro Thread pro Zyklus versendet werden sollen
• Setzen Sie Cmask = 1, INV = 1, um die Stillstandszyklen zu zählen.

In der Regel sind blockierte Zyklen Zyklen, in denen der Prozessor auf etwas wartet (z. B. Speicher, der nach dem Ausführen eines Ladevorgangs eingespeist wird) und keine anderen Aufgaben zu erledigen hat. Darüber hinaus ist der Frontend-Teil der CPU die Hardware, die für das Abrufen und Dekodieren von Anweisungen (Konvertieren in UOPs) verantwortlich ist, während der Backend-Teil für die effektive Ausführung der UOPs verantwortlich ist.

Ein CPU-Zyklus wird "blockiert", wenn die Pipeline währenddessen nicht vorrückt.

Die Prozessor-Pipeline besteht aus vielen Stufen: Das Front-End ist eine Gruppe dieser Stufen, die für die Abruf- und Dekodierungsphasen verantwortlich ist, während das Back-End die Anweisungen ausführt. Es gibt einen Puffer zwischen Front-End und Back-End. Wenn das erstere blockiert ist, kann das letztere noch einige Arbeiten erledigen.

Entnommen aus http://paolobernardi.wordpress.com/2012/08/07/playing-around-with-perf/

Laut Autor dieser Ereignisse sind sie lose definiert und werden durch verfügbare CPU-Leistungsindikatoren angenähert. Wie ich weiß, unterstützt perf keine Formeln zum Berechnen eines synthetischen Ereignisses basierend auf mehreren Hardwareereignissen, daher kann es keine Front-End- / Back-End-Stall-gebundene Methode aus dem Intel-Optimierungshandbuch (in VTune implementiert) http: // verwenden. www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf "B.3.2 Hierarchische Top-Down-Leistungscharakterisierungsmethode"

%FE_Bound = 100 * (IDQ_UOPS_NOT_DELIVERED.CORE / N ); 
%Bad_Speculation = 100 * ( (UOPS_ISSUED.ANY – UOPS_RETIRED.RETIRE_SLOTS + 4 * INT_MISC.RECOVERY_CYCLES ) / N) ; 
%Retiring = 100 * ( UOPS_RETIRED.RETIRE_SLOTS/ N) ; 
%BE_Bound = 100 * (1 – (FE_Bound + Retiring + Bad_Speculation) ) ; 
N = 4*CPU_CLK_UNHALTED.THREAD" (for SandyBridge)

Die richtigen Formeln können mit einigen externen Skripten verwendet werden, wie dies in Andi Kleens pmu-tools ( toplev.py) getan wurde : https://github.com/andikleen/pmu-tools (Quelle), http://halobates.de/blog/ S. 262 (Beschreibung):

% toplev.py -d -l2 numademo  100M stream
...
perf stat --log-fd 4 -x, -e
{r3079,r19c,r10401c3,r100030d,rc5,r10e,cycles,r400019c,r2c2,instructions}
{r15e,r60006a3,r30001b1,r40004a3,r8a2,r10001b1,cycles}
numademo 100M stream
...
BE      Backend Bound:                      72.03%
    This category reflects slots where no uops are being delivered due to a lack
    of required resources for accepting more uops in the    Backend of the pipeline.
 .....
FE      Frontend Bound:                     54.07%
This category reflects slots where the Frontend of the processor undersupplies
its Backend.

Commit, das blockierte-Zyklen-Frontend- und blockierte-Zyklen-Backend-Ereignisse anstelle des ursprünglichen Universums einführte stalled-cycles:

http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=8f62242246351b5a4bc0c1f00c0c7003edea128a

author  Ingo Molnar <mingo@el...>   2011-04-29 11:19:47 (GMT)
committer   Ingo Molnar <mingo@el...>   2011-04-29 12:23:58 (GMT)
commit  8f62242246351b5a4bc0c1f00c0c7003edea128a (patch)
tree    9021c99956e0f9dc64655aaa4309c0f0fdb055c9
parent  ede70290046043b2638204cab55e26ea1d0c6cd9 (diff)

Perf-Ereignisse: Fügen Sie generische Ereignisdefinitionen für blockierte Front-End- und Back-End-Zyklen hinzu. Fügen Sie zwei generische Hardware-Ereignisse hinzu: blockierte Front-End- und Back-End-Zyklen.

Diese Ereignisse messen die Bedingungen, unter denen die CPU Code ausführt, ihre Funktionen jedoch nicht vollständig genutzt werden. Das Verstehen und Analysieren solcher Situationen ist eine wichtige Unteraufgabe von Codeoptimierungs-Workflows.

Beide Ereignisse schränken die Leistung ein: Die meisten Front-End-Stalls werden in der Regel durch Verzweigungsfehler oder Cachemiss beim Abrufen von Anweisungen verursacht. Back-End-Stalls können durch verschiedene Ressourcenknappheit oder ineffiziente Anweisungsplanung verursacht werden.

Front-End-Stalls sind die wichtigeren: Code kann nicht schnell ausgeführt werden, wenn der Anweisungsstrom nicht aufrechterhalten wird.

Ein überlastetes Back-End kann zu Verzögerungen im Front-End führen und muss daher ebenfalls im Auge behalten werden.

Die genaue Zusammensetzung hängt stark von der Programmlogik und dem Befehlsmix ab.

Wir verwenden die Begriffe "Stall", "Front-End" und "Back-End" lose und versuchen, die besten verfügbaren Ereignisse von bestimmten CPUs zu verwenden, die sich diesen Konzepten annähern.

Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Frederic Weisbecker Link: http://lkml.kernel.org/n/[email protected] Unterzeichnet von: Ingo Molnar

    /* Install the stalled-cycles event: UOPS_EXECUTED.CORE_ACTIVE_CYCLES,c=1,i=1 */
-       intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES] = 0x1803fb1;
+       intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x1803fb1;

-   PERF_COUNT_HW_STALLED_CYCLES        = 7,
+   PERF_COUNT_HW_STALLED_CYCLES_FRONTEND   = 7,
+   PERF_COUNT_HW_STALLED_CYCLES_BACKEND    = 8,