1. 背景知識

1.1 與性能調優(yōu)相關的硬件特性

硬件特性之cache

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

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

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

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

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

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

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

硬件特性之分支預測

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

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

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

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

1.2 Tracepoints

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

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

2.Perf簡介

Perf是Linux內核自帶的系統(tǒng)性能優(yōu)化工具，原理是：

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

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

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

3.perf 的基本使用

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

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

3.1 Perf list，perf 事件

使用 perf list 命令可以列出所有能夠觸發(fā) 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] …不同的系統(tǒng)會列出不同的結果，在 2.6.35 版本的內核中，該列表已經(jīng)相當?shù)拈L，但無論有多少，我們可以將它們劃分為三類：

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

Software Event 是內核軟件產(chǎn)生的事件，比如進程切換，tick 數(shù)等 ;

Tracepoint event 是內核中的靜態(tài) tracepoint 所觸發(fā)的事件，這些 tracepoint 用來判斷程序運行期間內核的行為細節(jié)，比如 slab 分配器的分配次數(shù)等。

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

3.2 Perf stat

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

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

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

下面演示了 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 進行調優(yōu)應該要找到熱點 ( 即最耗時的代碼片段 )，再看看是否能夠提高熱點代碼的效率。

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

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

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

3.3perf Top

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

下面是 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

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

通過添加 -e 選項，您可以列出造成其他事件的 TopN 個進程 / 函數(shù)。比如 -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選項，可以記錄函數(shù)的調用關系，顯示類似下面這樣：

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 中的循環(huán)迭代為 20 次，BTB 溢出，所以處理器的分支預測將不準確。對于上面這句話我將簡要說明一下，但關于 BTB 的細節(jié)，請閱讀參考文獻 [6]。for 循環(huán)編譯成為 IA 匯編后如下：

清單 4. 循環(huán)的匯編

// 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:

可以看到，每次循環(huán)迭代中都有一個分支語句 jge，因此在運行過程中將有 20 次分支判斷。每次分支判斷都將寫入 BTB，但 BTB 是一個 ring buffer，16 個 slot 寫滿后便開始覆蓋。假如迭代次數(shù)正好為 16，或者小于 16，則完整的循環(huán)將全部寫入 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 進行調優(yōu)可以參考 Intel 公司出品的調優(yōu)手冊，其他的處理器可能有不同的方法，還希望讀者明鑒。

3.5 使用 tracepoint

當 perf 根據(jù) tick 時間點進行采樣后，人們便能夠得到內核代碼中的 hot spot。那什么時候需要使用 tracepoint 來采樣呢？我想人們使用 tracepoint 的基本需求是對內核的運行時行為的關心，如前所述，有些內核開發(fā)人員需要專注于特定的子系統(tǒng)，比如內存管理模塊。這便需要統(tǒng)計相關內核函數(shù)的運行情況。另外，內核行為對應用程序性能的影響也是不容忽視的：以之前的遺憾為例，假如時光倒流，我想我要做的是統(tǒng)計該應用程序運行期間究竟發(fā)生了多少次系統(tǒng)調用。在哪里發(fā)生的？下面我用 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 運行期間發(fā)生了多少次系統(tǒng)調用 ( 上例中有 101 次 )，多數(shù)系統(tǒng)調用都發(fā)生在哪些地方 (97% 都發(fā)生在 ld-2.12.so 中 )。有了這個報告，或許我能夠發(fā)現(xiàn)更多可以調優(yōu)的地方。比如函數(shù) foo() 中發(fā)生了過多的系統(tǒng)調用，那么我就可以思考是否有辦法減少其中有些不必要的系統(tǒng)調用。您可能會說 strace 也可以做同樣事情啊，的確，統(tǒng)計系統(tǒng)調用這件事完全可以用 strace 完成，但 perf 還可以干些別的，您所需要的就是修改 -e 選項后的字符串。羅列 tracepoint 實在是不太地道，本文當然不會這么做。但學習每一個 tracepoint 是有意義的，類似背單詞之于學習英語一樣，是一項緩慢痛苦卻不得不做的事情。

3.6 perf probe

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

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

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

[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 命令在內核函數(shù) schedule() 的第 12 行處加入了一個動態(tài) probe 點，和 tracepoint 的功能一樣，內核一旦運行到該 probe 點時，便會通知 perf?？梢岳斫鉃閯討B(tài)增加了一個新的 tracepoint。此后便可以用 record 命令的 -e 選項選擇該 probe 點，最后用 perf report 查看報表。如何解讀該報表便是見仁見智了，既然您在 shcedule() 的第 12 行加入了 probe 點，想必您知道自己為什么要統(tǒng)計它吧？

3.7 Perf sched

調度器的好壞直接影響一個系統(tǒng)的整體運行效率。在這個領域，內核黑客們常會發(fā)生爭執(zhí)，一個重要原因是對于不同的調度器，每個人給出的評測報告都各不相同，甚至常常有相反的結論。因此一個權威的統(tǒng)一的評測工具將對結束這種爭論有益。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 ’收集調度相關的數(shù)據(jù)，然后就可以用’ perf sched latency ’查看諸如調度延遲等和調度器相關的統(tǒng)計數(shù)據(jù)。其他三個命令也同樣讀取 record 收集到的數(shù)據(jù)并從其他不同的角度來展示這些數(shù)據(jù)。下面一一進行演示。

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 啟動時的統(tǒng)計信息。

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

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

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

首先是 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

星號表示調度事件發(fā)生所在的 CPU。

點號表示該 CPU 正在 IDLE。

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

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

下面是 replay 執(zhí)行的示例： $ 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

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

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

Sched message

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

Sched Pipe

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

Mem memcpy

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

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

3.9 perf lock

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

3.10 perf Kmem

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

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

3.11 Perf timechart

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

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

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

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

?