本頁面由 Cloud Translation API 翻譯而成。

使用 ftrace

ftrace 是一個調試工具，用於了解 Linux 內核內部發生的情況。以下部分詳細介紹了基本的 ftrace 功能、ftrace 與 atrace 的使用（捕獲內核事件）和動態 ftrace。

有關 systrace 不提供的高級 ftrace 功能的詳細信息，請參閱<kernel tree>/Documentation/trace/ftrace.txt中的 ftrace 文檔。

使用 atrace 捕獲內核事件

atrace ( frameworks/native/cmds/atrace ) 使用 ftrace 來捕獲內核事件。反過來，systrace.py（或更高版本的Catapult中的 run_systrace.py）使用 adb 在設備上運行 atrace。 atrace 執行以下操作：

通過設置屬性 ( debug.atrace.tags.enableflags ) 設置用戶模式跟踪。
通過寫入適當的 ftrace sysfs 節點來啟用所需的 ftrace 功能。但是，由於 ftrace 支持更多功能，您可以自己設置一些 sysfs 節點，然後使用 atrace。

除了啟動時跟踪之外，請依靠使用 atrace 將屬性設置為適當的值。該屬性是一個位掩碼，除了查看適當的標頭（可能會在 Android 版本之間發生變化）之外，沒有其他好的方法可以確定正確的值。

啟用 ftrace 事件

ftrace sysfs 節點位於/sys/kernel/tracing中，跟踪事件在/sys/kernel/tracing/events中分為多個類別。

要按類別啟用事件，請使用：

echo 1 > /sys/kernel/tracing/events/irq/enable

要基於每個事件啟用事件，請使用：

echo 1 > /sys/kernel/tracing/events/sched/sched_wakeup/enable

如果通過寫入 sysfs 節點啟用了額外的事件，它們將不會被 atrace 重置。 Qualcomm 設備啟動的常見模式是啟用kgsl （GPU）和mdss （顯示管道）跟踪點，然後使用 atrace 或systrace ：

adb shell "echo 1 > /sys/kernel/tracing/events/mdss/enable"
adb shell "echo 1 > /sys/kernel/tracing/events/kgsl/enable"
./systrace.py sched freq idle am wm gfx view binder_driver irq workq ss sync -t 10 -b 96000 -o full_trace.html

您也可以在不使用 atrace 或 systrace 的情況下使用 ftrace，這在您需要僅內核跟踪（或者如果您花時間手動編寫用戶模式跟踪屬性）時很有用。只運行 ftrace：

將緩衝區大小設置為對您的跟踪足夠大的值：
```
echo 96000 > /sys/kernel/tracing/buffer_size_kb
```

啟用跟踪：

echo 1 > /sys/kernel/tracing/tracing_on

運行測試，然後禁用跟踪：

echo 0 > /sys/kernel/tracing/tracing_on

轉儲跟踪：

cat /sys/kernel/tracing/trace > /data/local/tmp/trace_output

trace_output 以文本形式提供跟踪。要使用 Catapult 對其進行可視化，請從 GitHub 獲取Catapult 存儲庫並運行 trace2html：

catapult/tracing/bin/trace2html ~/path/to/trace_file

默認情況下，這會將trace_file.html寫入同一目錄中。

關聯事件

同時查看 Catapult 可視化和 ftrace 日誌通常很有用；例如，Catapult 無法顯示某些 ftrace 事件（尤其是特定於供應商的事件）。但是，Catapult 的時間戳與跟踪中的第一個事件或 atrace 轉儲的特定時間戳相關，而原始 ftrace 時間戳基於 Linux 內核中的特定絕對時鐘源。

從 Catapult 事件中查找給定的 ftrace 事件：

打開原始 ftrace 日誌。默認情況下，最新版本的 systrace 中的跟踪是壓縮的：
- 如果您使用--no-compress捕獲了您的 systrace，則它位於以 BEGIN TRACE 開頭的部分的 html 文件中。
- 如果沒有，請從Catapult 樹( tracing/bin/html2trace ) 運行 html2trace 以解壓縮跟踪。
在 Catapult 可視化中查找相對時間戳。
在包含tracing_mark_sync的跟踪的開頭找到一行。它應該看起來像這樣：
```
<5134>-5134  (-----) [003] ...1    68.104349: tracing_mark_write: trace_event_clock_sync: parent_ts=68.104286
```
如果此行不存在（或者如果您使用 ftrace 而不使用 atrace），那麼時間將與 ftrace 日誌中的第一個事件相對。
1. 將相對時間戳（以毫秒為單位）添加到parent_ts中的值（以秒為單位）。
2. 搜索新的時間戳。

這些步驟應該讓您參加（或至少非常接近）活動。

使用動態 ftrace

當 systrace 和標準 ftrace 不足時，還有最後一個可用的資源：動態 ftrace 。動態 ftrace 涉及在啟動後重寫內核代碼，因此出於安全原因，它在生產內核中不可用。然而，2015 年和 2016 年的每一個困難的性能錯誤最終都是使用動態 ftrace 造成的。它對於調試不間斷睡眠特別強大，因為每次點擊觸發不間斷睡眠的函數時，您都可以在內核中獲得堆棧跟踪。您還可以調試禁用中斷和搶占的部分，這對於證明問題非常有用。

要打開動態 ftrace，請編輯內核的 defconfig：

刪除 CONFIG_STRICT_MEMORY_RWX（如果存在）。如果您使用的是 3.18 或更高版本以及 arm64，則它不存在。
添加以下內容：CONFIG_DYNAMIC_FTRACE=y、CONFIG_FUNCTION_TRACER=y、CONFIG_IRQSOFF_TRACER=y、CONFIG_FUNCTION_PROFILER=y 和 CONFIG_PREEMPT_TRACER=y
重建並啟動新內核。
運行以下命令檢查可用的跟踪器：
```
cat /sys/kernel/tracing/available_tracers
```
確認命令返回function 、 irqsoff 、 preemptoff和preemptirqsoff 。

運行以下命令以確保動態 ftrace 正常工作：

cat /sys/kernel/tracing/available_filter_functions | grep <a function you care about>

完成這些步驟後，您就可以使用動態 ftrace、函數分析器、irqsoff 分析器和 preemptoff 分析器。我們強烈建議在使用它們之前閱讀有關這些主題的 ftrace 文檔，因為它們功能強大但很複雜。 irqsoff 和 preemptoff 主要用於確認驅動程序可能將中斷或搶占關閉時間過長。

函數分析器是解決性能問題的最佳選擇，通常用於找出函數被調用的位置。

顯示問題：HDR 照片 + 旋轉取景器

在這個問題中，使用 Pixel XL 拍攝 HDR+ 照片然後立即旋轉取景器每次都會導致卡頓。我們使用函數分析器在不到一小時的時間內調試了問題。要跟隨示例，請下載跟踪的 zip 文件（其中還包括本節中提到的其他跟踪），解壓縮文件，然後在瀏覽器中打開 trace_30898724.html 文件。

跟踪顯示 cameraserver 進程中的多個線程在ion_client_destroy上的不間斷睡眠中阻塞。這是一個昂貴的函數，但應該很少調用它，因為 ion 客戶端應該包含許多分配。最初，責任歸咎於 Halide 中的 Hexagon 代碼，這確實是罪魁禍首之一（它為每個離子分配創建一個新客戶端，並在分配被釋放時銷毀該客戶端，這太昂貴了）。為所有 Hexagon 分配遷移到單個 ion 客戶端改善了這種情況，但卡頓並沒有得到解決。

此時我們需要知道是誰在調用ion_client_destroy ，所以是時候使用函數分析器了：

由於編譯器有時會重命名函數，因此請使用以下命令確認ion_client_destroy是否存在：
```
cat /sys/kernel/tracing/available_filter_functions | grep ion_client_destroy
```

確認存在後，將其用作 ftrace 過濾器：

echo ion_client_destroy > /sys/kernel/tracing/set_ftrace_filter

打開函數分析器：

echo function > /sys/kernel/tracing/current_tracer

每當調用過濾器函數時打開堆棧跟踪：

echo func_stack_trace > /sys/kernel/tracing/trace_options

增加緩衝區大小：

echo 64000 > /sys/kernel/tracing/buffer_size_kb

打開跟踪：
```
echo 1 > /sys/kernel/tracing/trace_on
```

運行測試並獲取跟踪：

cat /sys/kernel/tracing/trace > /data/local/tmp/trace

查看跟踪以查看大量堆棧跟踪：

    cameraserver-643   [003] ...1    94.192991: ion_client_destroy <-ion_release
    cameraserver-643   [003] ...1    94.192997: <stack trace>
 => ftrace_ops_no_ops
 => ftrace_graph_call
 => ion_client_destroy
 => ion_release
 => __fput
 => ____fput
 => task_work_run
 => do_notify_resume
 => work_pending

根據對 ion 驅動程序的檢查，我們可以看到ion_client_destroy正在被關閉 fd 到/dev/ion的用戶空間函數發送垃圾郵件，而不是隨機內核驅動程序。通過在 Android 代碼庫中搜索\"/dev/ion\" ，我們發現有幾個供應商驅動程序與 Hexagon 驅動程序執行相同的操作，並在每次需要時打開/關閉/dev/ion （創建和銷毀新的 ion 客戶端）新的離子分配。將它們更改為在進程的生命週期內使用單個離子客戶端修復了該錯誤。

如果來自函數探查器的數據不夠具體，您可以將 ftrace 跟踪點與函數探查器結合使用。 ftrace 事件可以以與往常完全相同的方式啟用，它們將與您的跟踪交錯。如果在您要調試的特定函數中偶爾出現長時間不間斷睡眠，那就太好了：將 ftrace 過濾器設置為您想要的函數，啟用跟踪點，進行跟踪。您可以使用trace2html解析生成的跟踪，找到所需的事件，然後在原始跟踪中獲取附近的堆棧跟踪。

使用 lockstat

有時，ftrace 還不夠，您確實需要調試似乎是內核鎖爭用的問題。還有一個值得嘗試的內核選項： CONFIG_LOCK_STAT 。這是最後的手段，因為在 Android 設備上工作非常困難，因為它使內核的大小超出了大多數設備的處理能力。

但是，lockstat 使用調試鎖定基礎結構，這對許多其他應用程序很有用。每個從事設備啟動工作的人都應該想辦法讓該選項在每個設備上工作，因為有時你會想“如果我能打開LOCK_STAT ，我可以在五分鐘內確認或反駁這個問題，而不是五天。”

顯示問題：當內核處於最大負載且非 SCHED_FIFO 時，SCHED_FIFO 停止

在此問題中，當所有內核都處於非 SCHED_FIFO 線程的最大負載時，SCHED_FIFO 線程停止。我們有痕跡顯示 VR 應用程序中的 fd 存在顯著的鎖定爭用，但我們無法輕鬆識別正在使用的 fd。要跟隨示例，請下載跟踪的 zip 文件（其中還包括本節中提到的其他跟踪），解壓縮文件，然後在瀏覽器中打開 trace_30905547.html 文件。

我們假設 ftrace 本身是鎖爭用的源頭，此時低優先級線程將開始寫入 ftrace 管道，然後在釋放鎖之前被搶占。這是最壞的情況，由於混合了寫入 ftrace 標記的極低優先級線程以及一些在 CPU 上旋轉以模擬完全加載的設備的更高優先級線程，這種情況更加嚴重。

由於我們無法使用 ftrace 進行調試，我們讓LOCK_STAT工作，然後關閉應用程序的所有其他跟踪。結果顯示鎖爭用實際上來自 ftrace，因為當 ftrace 未運行時，鎖跟踪中沒有出現任何爭用。

如果您可以使用 config 選項啟動內核，則鎖定跟踪類似於 ftrace：

啟用跟踪：
```
echo 1 > /proc/sys/kernel/lock_stat
```
運行你的測試。
禁用跟踪：
```
echo 0 > /proc/sys/kernel/lock_stat
```

轉儲您的跟踪：

cat /proc/lock_stat > /data/local/tmp/lock_stat

有關解釋結果輸出的幫助，請參閱<kernel>/Documentation/locking/lockstat.txt中的 lockstat 文檔。

使用供應商跟踪點

首先使用上游跟踪點，但有時您需要使用供應商跟踪點：

  { "gfx",        "Graphics",         ATRACE_TAG_GRAPHICS, {
        { OPT,      "events/mdss/enable" },
        { OPT,      "events/sde/enable" },
        { OPT,      "events/mali_systrace/enable" },
    } },

跟踪點可通過 HAL 服務擴展，允許您添加設備特定的跟踪點/類別。跟踪點與 perfetto、atrace/systrace 和設備上的系統跟踪應用程序集成。

用於實現跟踪點/類別的 API 是：

listCategories() 生成（vec<TracingCategory> 類別）；
enableCategories(vec<string> categories) 生成（狀態狀態）；
disableAllCategories() 生成（狀態狀態）；

有關詳細信息，請參閱AOSP中的 HAL 定義和默認實現：