? ? ?如果你對你的進程的響應時間極其苛刻，有一天你發現你的進程響應時間變慢了，而恰好這個機器上也有其他的進程在跟你的進程爭用CPU，你想看看你的進程被內核調度的情況，那么你需要用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 就提供了最詳細，最底層的細節報告。

pipe-test-100k-13520 [001] 1254.354513808: sched_stat_wait: task: pipe-test-100k:13521 wait: 5362 [ns] pipe-test-100k-13520 [001] 1254.354514876: sched_switch: task pipe-test-100k:13520 [120] (S) ==> pipe-test-100k:13521 [120] :13521-13521 [001] 1254.354517927: sched_stat_runtime: task: pipe-test-100k:13521 runtime: 5092 [ns], vruntime: 133967391150 [ns] :13521-13521 [001] 1254.354518984: sched_stat_sleep: task: pipe-test-100k:13520 sleep: 5092 [ns] :13521-13521 [001] 1254.354520011: sched_wakeup: task pipe-test-100k:13520 [120] success=1 [001]

要理解以上的信息，必須對調度器的源代碼有一定了解，對一般用戶而言，理解他們十分不易。幸好這些信息一般也只有編寫調度器的人感興趣。。。

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

總結

以上是生活随笔為你收集整理的perf之sched的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。