1. 背景知識

1.1 與性能調優相關的硬件特性

硬件特性之cache

內存讀寫是很快的，但還是無法和處理器的指令執行速度相比。為了從內存中讀取指令和數據，處理器需要等待，用處理器的時間來衡量，這種等待非常漫長。Cache 是一種 SRAM，它的讀寫速率非常快，能和處理器處理速度相匹配。因此將常用的數據保存在 cache 中，處理器便無須等待，從而提高性能。Cache 的尺寸一般都很小，充分利用 cache 是軟件調優非常重要的部分。

硬件特性之流水線，超標量體系結構，亂序執行

提高性能最有效的方式之一就是并行。處理器在硬件設計時也盡可能地并行，比如流水線，超標量體系結構以及亂序執行。

處理器處理一條指令需要分多個步驟完成，比如先取指令，然后完成運算，最后將計算結果輸出到總線上。第一條指令在運算時，第二條指令已經在取指了;而第一條指令輸出結果時，第二條指令則又可以運算了，而第三天指令也已經取指了。這樣從長期看來，像是三條指令在同時執行。在處理器內部，這可以看作一個三級流水線。

超標量（superscalar）指一個時鐘周期發射多條指令的流水線機器架構，比如 Intel 的 Pentium 處理器，內部有兩個執行單元，在一個時鐘周期內允許執行兩條指令。

在處理器內部，不同指令所需要的處理步驟和時鐘周期是不同的，如果嚴格按照程序的執行順序執行，那么就無法充分利用處理器的流水線。因此指令有可能被亂序執行。

上述三種并行技術對所執行的指令有一個基本要求，即相鄰的指令相互沒有依賴關系。假如某條指令需要依賴前面一條指令的執行結果數據，那么 pipeline 便失去作用，因為第二條指令必須等待第一條指令完成。因此好的軟件必須盡量避免這種代碼的生成。

硬件特性之分支預測

分支指令對軟件性能有比較大的影響。尤其是當處理器采用流水線設計之后，假設流水線有三級，當前進入流水的第一條指令為分支指令。假設處理器順序讀取指令，那么如果分支的結果是跳轉到其他指令，那么被處理器流水線預取的后續兩條指令都將被放棄，從而影響性能。為此，很多處理器都提供了分支預測功能，根據同一條指令的歷史執行記錄進行預測，讀取最可能的下一條指令，而并非順序讀取指令。

分支預測對軟件結構有一些要求，對于重復性的分支指令序列，分支預測硬件能得到較好的預測結果，而對于類似 switch case 一類的程序結構，則往往無法得到理想的預測結果。

上面介紹的幾種處理器特性對軟件的性能有很大的影響，然而依賴時鐘進行定期采樣的 profiler 模式無法揭示程序對這些處理器硬件特性的使用情況。處理器廠商針對這種情況，在硬件中加入了 PMU 單元，即 performance monitor unit。PMU 允許軟件針對某種硬件事件設置 counter，此后處理器便開始統計該事件的發生次數，當發生的次數超過 counter 內設置的值后，便產生中斷。比如 cache miss 達到某個值后，PMU 便能產生相應的中斷。

捕獲這些中斷，便可以考察程序對這些硬件特性的利用效率了。

1.2 Tracepoints

Tracepoint 是散落在內核源代碼中的一些 hook，一旦使能，它們便可以在特定的代碼被運行到時被觸發，這一特性可以被各種 trace/debug 工具所使用。Perf 就是該特性的用戶之一。

假如您想知道在應用程序運行期間，內核內存管理模塊的行為，便可以利用潛伏在 slab 分配器中的 tracepoint。當內核運行到這些 tracepoint 時，便會通知 perf。Perf 將 tracepoint 產生的事件記錄下來，生成報告，通過分析這些報告，調優人員便可以了解程序運行時期內核的種種細節，對性能癥狀作出更準確的診斷。

2.Perf簡介

Perf是Linux內核自帶的系統性能優化工具，原理是：

CPU的PMU registers中Get/Set performance counters來獲得諸如instructions executed, cache-missed suffered, branches mispredicted等信息。linux?kernel對這些registers進行了一系列抽象，所以你可以按進程，按CPU或者按counter group等不同類別來查看Sample信息。

通過Perf，應用程序可以利用 PMU，tracepoint 和內核中的特殊計數器來進行性能統計。它不但可以分析指定應用程序的性能問題 (per thread)，也可以用來分析內核的性能問題，當然也可以同時分析應用代碼和內核，從而全面理解應用程序中的性能瓶頸。

Perf 不僅可以用于應用程序的性能統計分析，也可以應用于內核代碼的性能統計和分析。得益于其優秀的體系結構設計，越來越多的新功能被加入 Perf，使其已經成為一個多功能的性能統計工具集 。

3.perf 的基本使用

性能調優工具如 perf，Oprofile 等的基本原理都是對被監測對象進行采樣，最簡單的情形是根據 tick 中斷進行采樣，即在 tick 中斷內觸發采樣點，在采樣點里判斷程序當時的上下文。假如一個程序 90% 的時間都花費在函數 foo() 上，那么 90% 的采樣點都應該落在函數 foo() 的上下文中。運氣不可捉摸，但我想只要采樣頻率足夠高，采樣時間足夠長，那么以上推論就比較可靠。因此，通過 tick 觸發采樣，我們便可以了解程序中哪些地方最耗時間，從而重點分析。稍微擴展一下思路，就可以發現改變采樣的觸發條件使得我們可以獲得不同的統計數據：以時間點 ( 如 tick) 作為事件觸發采樣便可以獲知程序運行時間的分布。以 cache miss 事件觸發采樣便可以知道 cache miss 的分布，即 cache 失效經常發生在哪些程序代碼中。如此等等。

因此讓我們先來了解一下 perf 中能夠觸發采樣的事件有哪些。

3.1 Perf list，perf 事件

使用 perf list 命令可以列出所有能夠觸發 perf 采樣點的事件。比如 # perf list List of pre-defined events (to be used in -e): cpu-cycles OR cycles [Hardware event] instructions [Hardware event] … cpu-clock [Software event] task-clock [Software event] context-switches OR cs [Software event] … ext4:ext4_allocate_inode [Tracepoint event] kmem:kmalloc [Tracepoint event] module:module_load [Tracepoint event] workqueue:workqueue_execution [Tracepoint event] sched:sched_{wakeup,switch} [Tracepoint event] syscalls:sys_{enter,exit}_epoll_wait [Tracepoint event] …不同的系統會列出不同的結果，在 2.6.35 版本的內核中，該列表已經相當的長，但無論有多少，我們可以將它們劃分為三類：

Hardware Event 是由 PMU 硬件產生的事件，比如 cache 命中，當您需要了解程序對硬件特性的使用情況時，便需要對這些事件進行采樣；

Software Event 是內核軟件產生的事件，比如進程切換，tick 數等 ;

Tracepoint event 是內核中的靜態 tracepoint 所觸發的事件，這些 tracepoint 用來判斷程序運行期間內核的行為細節，比如 slab 分配器的分配次數等。

上述每一個事件都可以用于采樣，并生成一項統計數據，時至今日，尚沒有文檔對每一個 event 的含義進行詳細解釋。

3.2 Perf stat

面對一個問題程序，最好采用自頂向下的策略。先整體看看該程序運行時各種統計事件的大概，再針對某些方向深入細節。而不要一下子扎進瑣碎細節，會一葉障目的。

有些程序慢是因為計算量太大，其多數時間都應該在使用 CPU 進行計算，這叫做 CPU bound 型；有些程序慢是因為過多的 IO，這種時候其 CPU 利用率應該不高，這叫做 IO bound 型；對于 CPU bound 程序的調優和 IO bound 的調優是不同的。

如果您認同這些說法的話，Perf stat 應該是您最先使用的一個工具。它通過概括精簡的方式提供被調試程序運行的整體情況和匯總數據。

下面演示了 perf stat 針對程序 t1 的輸出：

$perf stat ./t1 Performance counter stats for './t1':

262.738415 task-clock-msecs # 0.991 CPUs 2 context-switches # 0.000 M/sec 1 CPU-migrations # 0.000 M/sec 81 page-faults # 0.000 M/sec 9478851 cycles # 36.077 M/sec (scaled from 98.24%) 6771 instructions # 0.001 IPC (scaled from 98.99%) 111114049 branches # 422.908 M/sec (scaled from 99.37%) 8495 branch-misses # 0.008 % (scaled from 95.91%) 12152161 cache-references # 46.252 M/sec (scaled from 96.16%) 7245338 cache-misses # 27.576 M/sec (scaled from 95.49%) 0.265238069 seconds time elapsed

上面告訴我們，程序 t1 是一個 CPU bound 型，因為 task-clock-msecs 接近 1。

對 t1 進行調優應該要找到熱點 ( 即最耗時的代碼片段 )，再看看是否能夠提高熱點代碼的效率。

缺省情況下，除了 task-clock-msecs 之外，perf stat 還給出了其他幾個最常用的統計信息：

Task-clock-msecs：CPU 利用率，該值高，說明程序的多數時間花費在 CPU 計算上而非 IO。 Context-switches：進程切換次數，記錄了程序運行過程中發生了多少次進程切換，頻繁的進程切換是應該避免的。 Cache-misses：程序運行過程中總體的 cache 利用情況，如果該值過高，說明程序的 cache 利用不好 CPU-migrations：表示進程 t1 運行過程中發生了多少次 CPU 遷移，即被調度器從一個 CPU 轉移到另外一個 CPU 上運行。 Cycles：處理器時鐘，一條機器指令可能需要多個 cycles， Instructions: 機器指令數目。 IPC：是 Instructions/Cycles 的比值，該值越大越好，說明程序充分利用了處理器的特性。 Cache-references: cache 命中的次數 Cache-misses: cache 失效的次數。

通過指定 -e 選項，您可以改變 perf stat 的缺省事件 ( 關于事件，在上一小節已經說明，可以通過 perf list 來查看 )。假如您已經有很多的調優經驗，可能會使用 -e 選項來查看您所感興趣的特殊的事件。

3.3perf Top

Perf top 用于實時顯示當前系統的性能統計信息。該命令主要用來觀察整個系統當前的狀態，比如可以通過查看該命令的輸出來查看當前系統最耗時的內核函數或某個用戶進程。

下面是 perf top 的可能輸出：

PerfTop: 705 irqs/sec kernel:60.4% [1000Hz cycles] -------------------------------------------------- sampl pcnt function DSO 1503.00 49.2% t2 72.00 2.2% pthread_mutex_lock /lib/libpthread-2.12.so 68.00 2.1% delay_tsc [kernel.kallsyms] 55.00 1.7% aes_dec_blk [aes_i586] 55.00 1.7% drm_clflush_pages [drm] 52.00 1.6% system_call [kernel.kallsyms] 49.00 1.5% __memcpy_ssse3 /lib/libc-2.12.so 48.00 1.4% __strstr_ia32 /lib/libc-2.12.so 46.00 1.4% unix_poll [kernel.kallsyms] 42.00 1.3% __ieee754_pow /lib/libm-2.12.so 41.00 1.2% do_select [kernel.kallsyms] 40.00 1.2% pixman_rasterize_edges libpixman-1.so.0.18.0 37.00 1.1% _raw_spin_lock_irqsave [kernel.kallsyms] 36.00 1.1% _int_malloc /lib/libc-2.12.so ^C

很容易便發現 t2 是需要關注的可疑程序。不過其作案手法太簡單：肆無忌憚地浪費著 CPU。所以我們不用再做什么其他的事情便可以找到問題所在。但現實生活中，影響性能的程序一般都不會如此愚蠢，所以我們往往還需要使用其他的 perf 工具進一步分析。

通過添加 -e 選項，您可以列出造成其他事件的 TopN 個進程 / 函數。比如 -e cache-miss，用來看看誰造成的 cache miss 最多。

3.4 使用 perf record, 解讀 report

lenny@hbt:~/test$ perf record ./a.out [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.015 MB perf.data (~656 samples) ] lenny@hbt:~/test$ perf report Events: 12 cycles 62.29% a.out a.out [.] longa 35.17% a.out [kernel.kallsyms] [k] unmap_vmas 1.76% a.out [kernel.kallsyms] [k] __schedule 0.75% a.out [kernel.kallsyms] [k] ____cache_alloc 0.03% a.out [kernel.kallsyms] [k] native_write_msr_safe

perf record時加上-g選項，可以記錄函數的調用關系，顯示類似下面這樣：

lenny@hbt:~/test$ perf record -g ./a.out [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.016 MB perf.data (~701 samples) ] lenny@hbt:~/test$ perf report Events: 14 cycles - 87.12% a.out a.out [.] longa - longa - 52.91% fun1 main __libc_start_main - 47.09% fun2 main __libc_start_main + 9.12% a.out [kernel.kallsyms] [k] vm_normal_page + 3.48% a.out [kernel.kallsyms] [k] _cond_resched + 0.28% a.out [kernel.kallsyms] [k] native_write_msr_safe

***使用 PMU 的例子下面這個例子 t3 參考了文章“Branch and Loop Reorganization to Prevent Mispredicts”該例子考察程序對奔騰處理器分支預測的利用率，如前所述，分支預測能夠顯著提高處理器的性能，而分支預測失敗則顯著降低處理器的性能。首先給出一個存在 BTB 失效的例子：

清單 3. 存在 BTB 失效的例子程序

//test.c #include #include void foo() { int i,j; for(i=0; i< 10; i++) j+=2; } int main(void) { int i; for(i = 0; i< 100000000; i++) foo(); return 0; }

用 gcc 編譯生成測試程序 t3: gcc – o t3 – O0 test.c

用 perf stat 考察分支預測的使用情況： [lm@ovispoly perf]$ ./perf stat ./t3

Performance counter stats for './t3': 6240.758394 task-clock-msecs # 0.995 CPUs 126 context-switches # 0.000 M/sec 12 CPU-migrations # 0.000 M/sec 80 page-faults # 0.000 M/sec 17683221 cycles # 2.834 M/sec (scaled from 99.78%) 10218147 instructions # 0.578 IPC (scaled from 99.83%) 2491317951 branches # 399.201 M/sec (scaled from 99.88%) 636140932 branch-misses # 25.534 % (scaled from 99.63%) 126383570 cache-references # 20.251 M/sec (scaled from 99.68%) 942937348 cache-misses # 151.093 M/sec (scaled from 99.58%) 6.271917679 seconds time elapsed

可以看到 branche-misses 的情況比較嚴重，25% 左右。我測試使用的機器的處理器為 Pentium4，其 BTB 的大小為 16。而 test.c 中的循環迭代為 20 次，BTB 溢出，所以處理器的分支預測將不準確。對于上面這句話我將簡要說明一下，但關于 BTB 的細節，請閱讀參考文獻 [6]。for 循環編譯成為 IA 匯編后如下：

清單 4. 循環的匯編

// C code for ( i=0; i < 20; i++ ) { … } //Assembly code; mov esi, data mov ecx, 0 ForLoop: cmp ecx, 20 jge EndForLoop … add ecx, 1 jmp ForLoop EndForLoop:

可以看到，每次循環迭代中都有一個分支語句 jge，因此在運行過程中將有 20 次分支判斷。每次分支判斷都將寫入 BTB，但 BTB 是一個 ring buffer，16 個 slot 寫滿后便開始覆蓋。假如迭代次數正好為 16，或者小于 16，則完整的循環將全部寫入 BTB。

清單 5. 沒有 BTB 失效的代碼

#include #include void foo() { int i,j; for(i=0; i< 10; i++) j+=2; } int main(void) { int i; for(i = 0; i< 100000000; i++) foo(); return 0; }

此時再次用 perf stat 采樣得到如下結果： [lm@ovispoly perf]$ ./perf stat ./t3

Performance counter stats for './t3: 2784.004851 task-clock-msecs # 0.927 CPUs 90 context-switches # 0.000 M/sec 8 CPU-migrations # 0.000 M/sec 81 page-faults # 0.000 M/sec 33632545 cycles # 12.081 M/sec (scaled from 99.63%) 42996 instructions # 0.001 IPC (scaled from 99.71%) 1474321780 branches # 529.569 M/sec (scaled from 99.78%) 49733 branch-misses # 0.003 % (scaled from 99.35%) 7073107 cache-references # 2.541 M/sec (scaled from 99.42%) 47958540 cache-misses # 17.226 M/sec (scaled from 99.33%) 3.002673524 seconds time elapsed

Branch-misses 減少了。本例只是為了演示 perf 對 PMU 的使用，本身并無意義，關于充分利用 processor 進行調優可以參考 Intel 公司出品的調優手冊，其他的處理器可能有不同的方法，還希望讀者明鑒。

3.5 使用 tracepoint

當 perf 根據 tick 時間點進行采樣后，人們便能夠得到內核代碼中的 hot spot。那什么時候需要使用 tracepoint 來采樣呢？我想人們使用 tracepoint 的基本需求是對內核的運行時行為的關心，如前所述，有些內核開發人員需要專注于特定的子系統，比如內存管理模塊。這便需要統計相關內核函數的運行情況。另外，內核行為對應用程序性能的影響也是不容忽視的：以之前的遺憾為例，假如時光倒流，我想我要做的是統計該應用程序運行期間究竟發生了多少次系統調用。在哪里發生的？下面我用 ls 命令來演示 sys_enter 這個 tracepoint 的使用： [root@ovispoly /]# perf stat -e raw_syscalls:sys_enter ls bin dbg etc lib media opt root selinux sys usr boot dev home lost+found mnt proc sbin srv tmp var

Performance counter stats for 'ls':

101 raw_syscalls:sys_enter

0.003434730 seconds time elapsed

[root@ovispoly /]# perf record -e raw_syscalls:sys_enter ls

[root@ovispoly /]# perf report Failed to open .lib/ld-2.12.so, continuing without symbols # Samples: 70 # # Overhead Command Shared Object Symbol # ........ ............... ............... ...... # 97.14% ls ld-2.12.so [.] 0x0000000001629d 2.86% ls [vdso] [.] 0x00000000421424 # # (For a higher level overview, try: perf report --sort comm,dso) #

這個報告詳細說明了在 ls 運行期間發生了多少次系統調用 ( 上例中有 101 次 )，多數系統調用都發生在哪些地方 (97% 都發生在 ld-2.12.so 中 )。有了這個報告，或許我能夠發現更多可以調優的地方。比如函數 foo() 中發生了過多的系統調用，那么我就可以思考是否有辦法減少其中有些不必要的系統調用。您可能會說 strace 也可以做同樣事情啊，的確，統計系統調用這件事完全可以用 strace 完成，但 perf 還可以干些別的，您所需要的就是修改 -e 選項后的字符串。羅列 tracepoint 實在是不太地道，本文當然不會這么做。但學習每一個 tracepoint 是有意義的，類似背單詞之于學習英語一樣，是一項緩慢痛苦卻不得不做的事情。

3.6 perf probe

tracepoint 是靜態檢查點，意思是一旦它在哪里，便一直在那里了，您想讓它移動一步也是不可能的。內核代碼有多少行？我不知道，100 萬行是至少的吧，但目前 tracepoint 有多少呢？我最大膽的想象是不超過 1000 個。所以能夠動態地在想查看的地方插入動態監測點的意義是不言而喻的。

Perf 并不是第一個提供這個功能的軟件，systemTap 早就實現了。但假若您不選擇 RedHat 的發行版的話，安裝 systemTap 并不是件輕松愉快的事情。perf 是內核代碼包的一部分，所以使用和維護都非常方便。

我使用的 Linux 版本為 2.6.33。因此您自己做實驗時命令參數有可能不同。

[root@ovispoly perftest]# perf probe schedule:12 cpu Added new event: probe:schedule (on schedule+52 with cpu) You can now use it on all perf tools, such as: perf record -e probe:schedule -a sleep 1 [root@ovispoly perftest]# perf record -e probe:schedule -a sleep 1 Error, output file perf.data exists, use -A to append or -f to overwrite. [root@ovispoly perftest]# perf record -f -e probe:schedule -a sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.270 MB perf.data (~11811 samples) ] [root@ovispoly perftest]# perf report # Samples: 40 # # Overhead Command Shared Object Symbol # ........ ............... ................. ...... # 57.50% init 0 [k] 0000000000000000 30.00% firefox [vdso] [.] 0x0000000029c424 5.00% sleep [vdso] [.] 0x00000000ca7424 5.00% perf.2.6.33.3-8 [vdso] [.] 0x00000000ca7424 2.50% ksoftirqd/0 [kernel] [k] 0000000000000000 # # (For a higher level overview, try: perf report --sort comm,dso) #

上例利用 probe 命令在內核函數 schedule() 的第 12 行處加入了一個動態 probe 點，和 tracepoint 的功能一樣，內核一旦運行到該 probe 點時，便會通知 perf。可以理解為動態增加了一個新的 tracepoint。此后便可以用 record 命令的 -e 選項選擇該 probe 點，最后用 perf report 查看報表。如何解讀該報表便是見仁見智了，既然您在 shcedule() 的第 12 行加入了 probe 點，想必您知道自己為什么要統計它吧？

3.7 Perf sched

調度器的好壞直接影響一個系統的整體運行效率。在這個領域，內核黑客們常會發生爭執，一個重要原因是對于不同的調度器，每個人給出的評測報告都各不相同，甚至常常有相反的結論。因此一個權威的統一的評測工具將對結束這種爭論有益。Perf sched 便是這種嘗試。

Perf sched 有五個子命令：

perf sched record # low-overhead recording of arbitrary workloads perf sched latency # output per task latency metrics perf sched map # show summary/map of context-switching perf sched trace # output finegrained trace perf sched replay # replay a captured workload using simlated threads

用戶一般使用’ perf sched record ’收集調度相關的數據，然后就可以用’ perf sched latency ’查看諸如調度延遲等和調度器相關的統計數據。其他三個命令也同樣讀取 record 收集到的數據并從其他不同的角度來展示這些數據。下面一一進行演示。

perf sched record sleep 10 # record full system activity for 10 seconds perf sched latency --sort max # report latencies sorted by max ------------------------------------------------------------------------------------- Task | Runtime ms | Switches | Average delay ms | Maximum delay ms | ------------------------------------------------------------------------------------- :14086:14086 | 0.095 ms | 2 | avg: 3.445 ms | max: 6.891 ms | gnome-session:13792 | 31.713 ms | 102 | avg: 0.160 ms | max: 5.992 ms | metacity:14038 | 49.220 ms | 637 | avg: 0.066 ms | max: 5.942 ms | gconfd-2:13971 | 48.587 ms | 777 | avg: 0.047 ms | max: 5.793 ms | gnome-power-man:14050 | 140.601 ms | 434 | avg: 0.097 ms | max: 5.367 ms | python:14049 | 114.694 ms | 125 | avg: 0.120 ms | max: 5.343 ms | kblockd/1:236 | 3.458 ms | 498 | avg: 0.179 ms | max: 5.271 ms | Xorg:3122 | 1073.107 ms | 2920 | avg: 0.030 ms | max: 5.265 ms | dbus-daemon:2063 | 64.593 ms | 665 | avg: 0.103 ms | max: 4.730 ms | :14040:14040 | 30.786 ms | 255 | avg: 0.095 ms | max: 4.155 ms | events/1:8 | 0.105 ms | 13 | avg: 0.598 ms | max: 3.775 ms | console-kit-dae:2080 | 14.867 ms | 152 | avg: 0.142 ms | max: 3.760 ms | gnome-settings-:14023 | 572.653 ms | 979 | avg: 0.056 ms | max: 3.627 ms | ... ----------------------------------------------------------------------------------- TOTAL: | 3144.817 ms | 11654 | ---------------------------------------------------

上面的例子展示了一個 Gnome 啟動時的統計信息。

各個 column 的含義如下： Task: 進程的名字和 pid Runtime: 實際運行時間 Switches: 進程切換的次數 Average delay: 平均的調度延遲 Maximum delay: 最大延遲

這里最值得人們關注的是 Maximum delay，一般從這里可以看到對交互性影響最大的特性：調度延遲，如果調度延遲比較大，那么用戶就會感受到視頻或者音頻斷斷續續的。

其他的三個子命令提供了不同的視圖，一般是由調度器的開發人員或者對調度器內部實現感興趣的人們所使用。

首先是 map:

$ perf sched map ...

N1 O1 . . . S1 . . . B0 . *I0 C1 . M1 . 23002.773423 secs N1 O1 . *Q0 . S1 . . . B0 . I0 C1 . M1 . 23002.773423 secs N1 O1 . Q0 . S1 . . . B0 . *R1 C1 . M1 . 23002.773485 secs N1 O1 . Q0 . S1 . *S0 . B0 . R1 C1 . M1 . 23002.773478 secs *L0 O1 . Q0 . S1 . S0 . B0 . R1 C1 . M1 . 23002.773523 secs L0 O1 . *. . S1 . S0 . B0 . R1 C1 . M1 . 23002.773531 secs L0 O1 . . . S1 . S0 . B0 . R1 C1 *T1 M1 . 23002.773547 secs T1 => irqbalance:2089 L0 O1 . . . S1 . S0 . *P0 . R1 C1 T1 M1 . 23002.773549 secs *N1 O1 . . . S1 . S0 . P0 . R1 C1 T1 M1 . 23002.773566 secs N1 O1 . . . *J0 . S0 . P0 . R1 C1 T1 M1 . 23002.773571 secs N1 O1 . . . J0 . S0 *B0 P0 . R1 C1 T1 M1 . 23002.773592 secs N1 O1 . . . J0 . *U0 B0 P0 . R1 C1 T1 M1 . 23002.773582 secs N1 O1 . . . *S1 . U0 B0 P0 . R1 C1 T1 M1 . 23002.773604 secs

星號表示調度事件發生所在的 CPU。

點號表示該 CPU 正在 IDLE。

Map 的好處在于提供了一個的總的視圖，將成百上千的調度事件進行總結，顯示了系統任務在 CPU 之間的分布，假如有不好的調度遷移，比如一個任務沒有被及時遷移到 idle 的 CPU 卻被遷移到其他忙碌的 CPU，類似這種調度器的問題可以從 map 的報告中一眼看出來。如果說 map 提供了高度概括的總體的報告，那么 trace 就提供了最詳細，最底層的細節報告。

Perf replay 這個工具更是專門為調度器開發人員所設計，它試圖重放 perf.data 文件中所記錄的調度場景。很多情況下，一般用戶假如發現調度器的奇怪行為，他們也無法準確說明發生該情形的場景，或者一些測試場景不容易再次重現，或者僅僅是出于“偷懶”的目的，使用 perf replay，perf 將模擬 perf.data 中的場景，無需開發人員花費很多的時間去重現過去，這尤其利于調試過程，因為需要一而再，再而三地重復新的修改是否能改善原始的調度場景所發現的問題。

下面是 replay 執行的示例： $ perf sched replay run measurement overhead: 3771 nsecs sleep measurement overhead: 66617 nsecs the run test took 999708 nsecs the sleep test took 1097207 nsecs nr_run_events: 200221 nr_sleep_events: 200235 nr_wakeup_events: 100130 task 0 ( perf: 13519), nr_events: 148 task 1 ( perf: 13520), nr_events: 200037 task 2 ( pipe-test-100k: 13521), nr_events: 300090 task 3 ( ksoftirqd/0: 4), nr_events: 8 task 4 ( swapper: 0), nr_events: 170 task 5 ( gnome-power-man: 3192), nr_events: 3 task 6 ( gdm-simple-gree: 3234), nr_events: 3 task 7 ( Xorg: 3122), nr_events: 5 task 8 ( hald-addon-stor: 2234), nr_events: 27 task 9 ( ata/0: 321), nr_events: 29 task 10 ( scsi_eh_4: 704), nr_events: 37 task 11 ( events/1: 8), nr_events: 3 task 12 ( events/0: 7), nr_events: 6 task 13 ( flush-8:0: 6980), nr_events: 20 ------------------------------------------------------------ #1 : 2038.157, ravg: 2038.16, cpu: 0.09 / 0.09 #2 : 2042.153, ravg: 2038.56, cpu: 0.11 / 0.09 ^C

3.8 perf bench

除了調度器之外，很多時候人們都需要衡量自己的工作對系統性能的影響。benchmark 是衡量性能的標準方法，對于同一個目標，如果能夠有一個大家都承認的 benchmark，將非常有助于”提高內核性能”這項工作。

目前，就我所知，perf bench 提供了 3 個 benchmark:

Sched message

sched message 是從經典的測試程序 hackbench 移植而來，用來衡量調度器的性能，overhead 以及可擴展性。該 benchmark 啟動 N 個 reader/sender 進程或線程對，通過 IPC(socket 或者 pipe) 進行并發的讀寫。一般人們將 N 不斷加大來衡量調度器的可擴展性。Sched message 的用法及用途和 hackbench 一樣。

Sched Pipe

Sched pipe 從 Ingo Molnar 的 pipe-test-1m.c 移植而來。當初 Ingo 的原始程序是為了測試不同的調度器的性能和公平性的。其工作原理很簡單，兩個進程互相通過 pipe 拼命地發 1000000 個整數，進程 A 發給 B，同時 B 發給 A。。。因為 A 和 B 互相依賴，因此假如調度器不公平，對 A 比 B 好，那么 A 和 B 整體所需要的時間就會更長。

Mem memcpy

這個是 perf bench 的作者 Hitoshi Mitake 自己寫的一個執行 memcpy 的 benchmark。該測試衡量一個拷貝 1M 數據的 memcpy() 函數所花費的時間。我尚不明白該 benchmark 的使用場景。。。或許是一個例子，告訴人們如何利用 perf bench 框架開發更多的 benchmark 吧。

這三個 benchmark 給我們展示了一個可能的未來：不同語言，不同膚色，來自不同背景的人們將來會采用同樣的 benchmark，只要有一份 Linux 內核代碼即可。

3.9 perf lock

鎖是內核同步的方法，一旦加了鎖，其他準備加鎖的內核執行路徑就必須等待，降低了并行。因此對于鎖進行專門分析應該是調優的一項重要工作。

3.10 perf Kmem

Perf Kmem 專門收集內核 slab 分配器的相關事件。比如內存分配，釋放等。可以用來研究程序在哪里分配了大量內存，或者在什么地方產生碎片之類的和內存管理相關的問題。

Perf kmem 和 perf lock 實際上都是 perf tracepoint 的特例，您也完全可以用 Perf record – e kmem:?或者 perf record – e lock:?來完成同樣的功能。但重要的是，這些工具在內部對原始數據進行了匯總和分析，因而能夠產生信息更加明確更加有用的統計報表。

3.11 Perf timechart

很多 perf 命令都是為調試單個程序或者單個目的而設計。有些時候，性能問題并非由單個原因所引起，需要從各個角度一一查看。為此，人們常需要綜合利用各種工具，比如 top,vmstat,oprofile 或者 perf。這非常麻煩。

此外，前面介紹的所有工具都是基于命令行的，報告不夠直觀。更令人氣餒的是，一些報告中的參數令人費解。所以人們更愿意擁有一個“傻瓜式”的工具。

以上種種就是 perf timechart 的夢想，其靈感來源于 bootchart。采用“簡單”的圖形“一目了然”地揭示問題所在。

Timechart 可以顯示更詳細的信息，實際上是一個矢量圖形 SVG 格式，用 SVG viewer 的放大功能，我們可以將該圖的細節部分放大，timechart 的設計理念叫做”infinitely zoomable”。放大之后便可以看到一些更詳細的信息，類似網上的 google 地圖，找到國家之后，可以放大，看城市的分布，再放大，可以看到某個城市的街道分布，還可以放大以便得到更加詳細的信息。完整的 timechart 圖形和顏色解讀超出了本文的范圍，感興趣的讀者可以到作者 Arjan 的博客上查看。

?