爲什麼perf stat顯示「stalled-cycles-backend」爲<不支持>？

運行perf stat ls表明這一點：爲什麼perf stat顯示「stalled-cycles-backend」爲<不支持>？

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

爲什麼顯示爲「不支持」停頓週期，後臺？我需要什麼樣的CPU，硬件，內核或用戶空間軟件才能看到這個值？

目前在RHEL上使用Linux 3.12 for x86_64，在不同的Intel Core i5和i7系統（Ivy Bridge類型）上使用匹配的「perf」版本。它們都不支持停滯週期後端。

一些更多的信息：

$ 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

編輯：只是使用Linux 3.2（32位）試過這種的AMD羿龍II X6 1045T CPU上的Ubuntu 12.04下 - 在這裏它顯示值都停滯-cycles-front和stalled-cycles-backend。

來源

2014-03-28 oliver

看起來像perf尚未更新以瞭解Ivy Bridge支持的所有性能監視事件。幸運的是，有一個通用的界面，雖然很麻煩，但您可以訪問完整的性能監控事件列表。當我快速查看時，我沒有在列表中看到stalled-cycles-backend，但也許我錯過了，或者他們已經將所有不同的事件分解了，可能會拖延後端。

我們先從

perf list --help

...顯示以下注意

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

...在

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

與你結束這種URL武裝起來..你想第19.3節

19.3第三代英特爾® 睿™處理器 第三代英特爾®酷睿™處理器和英特爾至強處理器E3-1200 V2產品系列性能監視事件都基於英特爾微架構代號Ivy Bridge的。它們支持表19-1中列出的架構性能監視事件。表19-5列出了處理器內核中的非架構性能監視事件。表19-5中的事件適用於具有以下值的DisplayFamily_DisplayModel編碼的CPUID簽名的處理器：06_3AH。

...所以architectural事件，你需要表19-1

19.1建築性能監視事件 建築性能事件在英特爾Core Solo和英特爾酷睿處理器中引入。它們也支持基於英特爾酷睿微體系結構的處理器。表19-1列出了可以使用通用性能計數器和關聯事件選擇寄存器配置的預定義架構性能事件。

**表19-1。建築性能事件

enter image description here

...現在到了棘手的部分，你把UMask Value作爲上2個十六進制數字和Event Num是一個4低2個十六進制數字十六進制數字硬件寄存器編號給予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.

...它說NNN，但你可以給它NNNN。讓我們驗證它是否有效，讓我們問perf stat將緩存未命中作爲符號事件名稱和來自表19-1的十六進制數字。爲了簡單起見，我們將調用date命令。

$ 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 

$

正如你可以看到兩個報告相同的數字，目前爲止這麼好。現在我們去表19-5非建築硬件寄存器，其中有太多太多列出在這裏，但我會列出幾個：

enter image description here

來源

2014-03-28 14:34:56 amdn

感謝extensicve答案！到目前爲止，我還沒有找到對應於stalled-cycles-frontend或stalled-cycles-backend的「原始」事件編號。對於前者，它應該是「-e r10e」，但這並不完全匹配;對於後者，它可能是'-e r1b1'根據http://stackoverflow.com/questions/22165299/;根據英特爾PDF，這將是UOPS_EXECUTED.THREAD - 不確定這是否合理？ – oliver

似乎像英特爾在發佈新的微架構時保留了表19-1「架構性能事件」中的數字，但其他可能與實現有關？不知道。 – amdn

漂亮而雄辯的答案。試過'perf stat -e r412e -e cache-missses date'，我得到了r412e和cache-missses的相同結果。但是當我對'perf stat -e r412e -e cache-missses real-slow-application'做同樣的處理時，我會在10秒內運行的應用程序中得到不同的結果。任何想法爲什麼？ – insumity

剛剛發現Re: perf, x86: Add parts of the remaining haswell PMU functionality：

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

因此，IIUC失速循環後端計數器在Ivy Bridge上太不可靠了，這就是內核開發者決定不支持它們的原因。

果然，Linux'perf_event_intel.c支持Nehalem，Xeon E7和SandyBridge的PERF_COUNT_HW_STALLED_CYCLES_BACKEND，但不支持IvyBridge。但IvyBridge支持PERF_COUNT_HW_STALLED_CYCLES_FRONTEND。

所以我想不會有辦法讓我當前的CPU上這個計數器 - 無論是交換機的CPU，或者使用在郵件中提到的完整的自上而下的方法（和描述here和here）

來源

2014-03-28 16:48:29 oliver

的perf（或其內核部分）未更新以支持您的CPU，因此perf無法將通用事件名稱「stalled-cycles-backend」映射到實際的HW事件。

在這種情況下，可以更容易地找到事件名稱;例如英特爾CPU優化手冊http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf（按類型對事件進行分組，並說明如何使用它們來測量各種部件）。沒有類似的AMD文件。

爲了無需人工轉換與PERF使用事件名稱爲原始的事件ID（如amdn中說，他的answer），您可以使用轉換腳本showevtinfo和perfmon2 check_events（libpfm4;示例文件夾），在文章中解釋說，「如何監視全範圍的CPU性能事件「by Bojan Nikolic http://www.bnikolic.co.uk/blog/hpc-prof-events.html。perfmon2知道AMD和Intel的CPU，並用C/C++

對於Intel CPU的最簡單的方法是由安迪Kleen的使用ocperf包裝在perf來自英特爾的開源Python項目在GitHub上https://github.com/andikleen/pmu-tools主辦的「PMU工具」並在此處介紹ML：https://lwn.net/Articles/556983/和Andi的博客http://halobates.de/blog/p/245

ocperf瞭解英特爾優化手冊中的所有英特爾事件名稱。

ocperf也將支持使用較老的linux內核的每個硬件事件。它擁有自己的tsv或json格式的數據庫，其所有硬件事件及其代碼位於https://download.01.org/perfmon/（pmu-tools中有自動下載程序），數據庫不斷由英特爾僱主更新。數據庫的格式記錄在自述：https://download.01.org/perfmon/readme.txt

對於Sandy Bridge的/ Ivy Bridge的或Haswell的，和仁3.10或更高版本，你也可以使用toplev.py腳本從「PMU工具」來調查性能。下面是它的作者，安迪Kleen的，http://halobates.de/blog/p/262「PMU的工具，第二部分：toplev」描述基於從艾哈邁德·亞辛"How to Tune Applications Using a Top-Down Characterization of Microarchitectural Issues「自上而下」的方法和"Top Down Analysis. Never lost with performance counters"

來源

2014-04-30 17:18:55 osgx

+1爲「自上而下」的方法，這是瓶頸分析的一個有用的起點 – Leeor

爲什麼perf stat顯示「stalled-cycles-backend」爲<不支持>？

回答

相關問題