本文首次發表於 實時 Linux 抖動分析 Step by step
前段時間有同學問到：
大家有顯示卡方面實時性調優經驗交流嗎？我現在是 x86，不加顯示任務實時性可以保持在 20us 內，如果加上顯示，抖動就飆升到 70us，其實顯示是輔助功能。
其實造成抖動的原因已經清楚了，但是要解決問題還得定位到具體的程式碼，到底是哪段程式碼造成了這麼大的抖動呢？
從問題本身來看，這個應該是可復現的，所以接下來就是要解決它。
解決這類問題通常是用專屬工具 Ftrace 的 Max Latency Tracing，大體用法可參考 Documentation/trace/ftrace.rst。
大體分析過程如下：
使用搶佔核心或者 preempt-rt 核心
如果用普通核心，請在核心 General setup 下 preemption model 開啟 low-latency desktop。
CONFIG_PREEMPT=y
複製程式碼從問題來看，應該是已經用上了實時搶佔核心，這時需要開啟如下配置：
CONFIG_PREEMPT_RT_FULL=y
複製程式碼如果沒有使用，得參考 實時 Linux 一文從 釋出地址 找到相應版本的 patch 打上，並針對所用板子做進一步優化，而且要關閉很多可能影響實時效能的除錯選項。
配置核心，開啟中斷和搶佔關閉等 tracer
在核心配置 Kernel Hacking 下 Tracers
--- Tracers
[*] Kernel Function Tracer
[*] Kernel Function Graph Tracer
[*] Interrupts-off Latency Tracer
[*] Preemption-off Latency Tracer
[*] Scheduling Latency Tracer
[*] Enable upbrobed-based dynamic events
[*] enable/disable function tracing dynamically
複製程式碼重新編譯核心，啟動到問題現場並開始分析
先確保能復現問題的場景是一直在跑的，然後就是參考上面 ftrace.rst 用法開始 tracing。
稍微補充幾點小技巧：
-
sys/kernel/tracing 掛載
預設這個目錄可能沒掛載，
$ mount -t tracefs none /sys/kernel/tracing 複製程式碼早期核心可能用的
/sys/kernel/debugfs/tracing目錄，需要先掛載debugfs如下：$ mount -t debugfs none /sys/kernel/debugfs 複製程式碼 -
tracers：irqsoff, preemptoff, preemptirqsoff
建議先用第三個，再逐步用第一個和第二個。第三個是兩個的或，如果先用第一個或者第二個，即使解決了發現的問題，也可能不是造成 max latency 的熱點路徑。
-
開始 tracing 前，清空歷史記錄
啟動新的
tracing之前，記得清空上次記錄，避免造成誤判，以irqsoff為例：echo 0 > options/function-trace echo irqsoff > current_tracer echo 1 > tracing_on echo 0 > tracing_max_latency do something for repeat the issue scene echo 0 > tracing_on cat trace > trace.log 複製程式碼
最後就是分析日誌和解決問題，原因不外乎是長時間關了搶佔或者關了中斷，這個就得具體問題具體分析，看情況是要做中斷執行緒化還是主動加排程點等等。
對於 tracing 日誌分析，類似 Android 上的 Systrace 圖形化分析工具，Linux 上有 kernelshark。