contributed by < MetalheadKen
>
/boot/grub/grub.cfg
的 boot 的參數,將開機命令 linux
後面加上 isolcpus=7
來讓第 7 個 CPU 在開機時就可以被保留下來。scaling_governor
為 performance為了進行效能量測,通常都會盡量避免修改原始碼並重新編譯。有鑑於此,這邊採取使用 ftrace 來進行效能分析,藉由透過 kprobe 和 kretprobe 來計算 kernel space 執行時間,以及透過 uprobe 和 uretprobe 來計算 user space 的執行時間。
為了要計算 kernel space 的執行時間,在這邊利用 kprobes 的技術來安插 probe 到想要量測的 function 中。
舉例來說,若要安插 probe 到 fibdrv.c
的 fib_read
的開頭的話可以這樣寫
而若要安插 probe 到 fibdrv.c
的 fib_read
的回傳結尾的話可以這樣寫
最後若要移除上面兩個 probe 的時候可以這樣寫
當透過 ftrace 追蹤時,當觸發 probe 的時候就會印出執行 probe 安插的地方的 CPU id、timestamp、irq 和 schedule 等相關資訊,如此一來就可以很輕鬆地進行程式分析。
與上面不同的是,為了要計算 user space 的執行時間,在這邊是使用 uprobes 而不是 kprobes
比較麻煩的是,與 kprobes 不同,uprobes 在 ftrace 並沒有像 perf-tools 中使用 uprobes 的方法一樣有一個比較直覺的方式撰寫,相反的如 kernel doc 所說,當我們要安插 probe 到 user space 的時候,要給予要插入的 offset 位置而不是要插入的 function name。
舉例來說,若要安插 probe 到 client.c
的 read
的時候我們需要透過 objdump
工具來搜尋 read
函式的 offset
由上面可知 read
的 offset 為 0x840
,因此我們可以這樣寫來安插 uprobe
最後比較麻煩的是,ftrace 最後會將結果全部輸出到 /sys/kernel/debug/tracing/trace
裡,因為沒辦法像 bpftrace 一樣可以在 runtime 的時候計算執行時間差,因此我們需要透過讀取檔案並提取我們要的資訊來計算執行的時間差。程式碼總結如下:
既然寫成 shell script,應避免 hardcoded path,例如下方的 USER_DIR
,可善用 dirname 一類的命令。
client_perf.sh
Makefile
之後執行 make plot
即可繪製結果成圖表
linux2020