本文首次發表于 實時 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。

---

本專欄作者首開視頻課，歡迎報名或引薦~

總結

以上是生活随笔為你收集整理的am335x linux内核烧写_实时 Linux 抖动分析 Step by step的全部內容，希望文章能夠幫你解決所遇到的問題。

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