Wie löst man "nicht gezählt" in perf?

Question

perf stat -d ./sample.out Ausgang ist:

Performance counter stats for './sample.out': 

      0.586266 task-clock (msec)   # 0.007 CPUs utilized   
       2 context-switches   # 0.003 M/sec     
       1 cpu-migrations   # 0.002 M/sec     
       116 page-faults    # 0.198 M/sec     
      7,35,790 cycles     # 1.255 GHz      [81.06%] 
    <not counted> stalled-cycles-frontend 
    <not supported> stalled-cycles-backend 
    <not counted> instructions    
    <not counted> branches     
    <not counted> branch-misses   
    <not supported> L1-dcache-loads:HG  
    <not counted> L1-dcache-load-misses:HG 
    <not counted> LLC-loads:HG    
    <not supported> LLC-load-misses:HG  

     0.088013919 seconds time elapsed 

ich lesen, warum von auftauchen wird. Aber ich bekomme sogar einfache Zähler wie Anweisungen, Zweige usw. Kann jemand vorschlagen, wie es funktioniert?

Interessante ist:

sudo perf stat Schlaf 3

gibt Ausgang:

Performance counter stats for 'sleep 3': 

      0.598484 task-clock (msec)   # 0.000 CPUs utilized   
       2 context-switches   # 0.003 M/sec     
       0 cpu-migrations   # 0.000 K/sec     
       181 page-faults    # 0.302 M/sec     
    <not counted> cycles     
    <not counted> stalled-cycles-frontend 
    <not supported> stalled-cycles-backend 
    <not counted> instructions    
    <not counted> branches     
    <not counted> branch-misses 

sudo perf stat -C 1 Schlaf 3

Performance counter stats for 'CPU(s) 1': 

     3002.640578 task-clock (msec)   # 1.001 CPUs utilized   [100.00%] 
       425 context-switches   # 0.142 K/sec     [100.00%] 
       9 cpu-migrations   # 0.003 K/sec     [100.00%] 
       5 page-faults    # 0.002 K/sec     
     7,82,97,019 cycles     # 0.026 GHz      [33.32%] 
     9,38,21,585 stalled-cycles-frontend # 119.83% frontend cycles idle [33.32%] 
    <not supported> stalled-cycles-backend 
     3,09,81,643 instructions    # 0.40 insns per cycle   
              # 3.03 stalled cycles per insn [33.32%] 
     70,15,390 branches     # 2.336 M/sec     [33.32%] 
      6,38,644 branch-misses    # 9.10% of all branches   [33.32%] 

     3.001075650 seconds time elapsed 

Warum funktioniert das unerwartet?

Danke

Answer 1

sudo perf stat -C 1 sleep 3 Profile alles, die auf CPU 1, alle Prozesse und Kernel-Code geschieht. Deshalb ist sudo erforderlich. Aus diesem Grund beträgt die Task-Clock ~ 3002 ms.

perf stat sleep 3 Profile nur den sleep(1) Prozess selbst (die nicht sudo braucht). Der Task-Takt hat es bei ~ 0,6 ms CPU-Zeit gemessen.

---

sleep macht kaum etwas; Die meisten Anweisungen, die ausgeführt werden, befinden sich im dynamischen Linker. Wie die @ osgx-Antwort darauf hinweist, fehlen Ihnen Zählungen, da perf nicht genügend Hardware-Zähler auf Ihrem Rechner hat, also multiplext. Die Zähler ohne Zählungen müssen aufgezeichnet worden sein, während sleep geschlafen hat und nicht ausgeführt wurde.

Für gute Ergebnisse, legen Sie Ihre Mikrobenchmark in eine Schleife, die mindestens hundert Millisekunden dauert, vorzugsweise ~ 1 Sekunde für ein gutes Signal-Rausch-Verhältnis, abhängig davon, welche Zähler Sie zählen.

Answer 2

Das typische Problem der perf stat -d für sehr kurze Programme sind nicht die statistischen Stichproben, sondern Multiplexen (Prozent in eckigen Klammern sagen [33%] - dieser Zähler gezählt wurde nur für rund 33% Zeit ausgeführt wird).

Sie bitten Ihr PMU, zu viele Ereignisse gleichzeitig zu überwachen, und perf ist nicht in der Lage, alle benötigten Zähler gleichzeitig auf echter Hardware (PMU - Performance Monitoring Unit der CPU) abzubilden. Eine typische PMU kann 4 oder 7 oder 8 unabhängige Zähler haben, aber die Anzahl kann durch zwei geteilt werden, wenn Sie eine SMT-Technologie aktiviert haben (z. B. HT - HyperThreading).

Wenn Sie verlangen, dass so viele Zähler gezählt werden (Sie haben 6 unterstützte HW-Ereignisse in Ihrer Perfstat-Ausgabe), werden alle in kleinere Gruppen unterteilt. Gruppen werden zu bestimmten Zeitpunkten vom Kernel geändert, wenn perf_events die Chance haben, sie zu ändern, zum Beispiel beim Task-Tick-Tick (~ 3 ms).

können Sie laufen in mehrere mit kleineren Gruppen von Ereignissen aufgeteilt - eine beliebige Anzahl von SW Veranstaltungen und 2-4 HW Ereignisse pro Lauf:

perf stat -e task-clock,page-faults,cycles,stalled-cycles-frontend 
perf stat -e task-clock,page-faults,cycles,instructions    
perf stat -e task-clock,page-faults,branches,branch-misses   
perf stat -e task-clock,page-faults,L1-dcache-load-misses:HG,LLC-loads:HG