實例分析

最近博主遇到 i2c 傳輸慢和中斷觸發慢的問題，一般這種【慢】的情況大都和【性能與功耗沖突】相關，研究了 Qos 系統，打了筆 patch 解決了。

中斷觸發慢：注冊的下降沿中斷，從下降沿打到芯片中，到跑到中斷處理函數，快則 270us，慢則 2.7ms。由于所做功能對中斷處理時間有要求，因此要解決中斷處理慢的問題。

抓 trace 分析

使用上次博主發的腳本，可以抓到 ftrace，這個腳本中博主使能了 sched_switch、sched_wakeup、irq、irq_handler_entry、irq_handler_exit、cpu_idle、pm_qos_update_request 等 event。這些 event 可以記錄下 CPU 調度和中斷處理情況。

從抓到的 trace 分析，中斷處理慢并不是由于 CPU loading 重導致的處理不及時，而是中斷來的時候，CPU0 處于 idle 狀態，而 kernel-5.10 以后除了特定的 feature，所有的中斷都默認發到 CPU0，這樣即便設置了中斷可以喚醒系統，把 CPU0 從 idle 轉為 active 也要 1ms。

問題確定后，就是如何處理的問題了。找了低功耗的同事，確認 CPU 在沒事情做的時候就是會進入 idle，即便在游戲場景，也不會禁止 CPU 進入 idle。

研究了一下 Linux 電源管理子系統，發現 Qos 有接口可以使用：在某一段時間內拉 Qos，可以讓 CPU 在這段時間不進入 idle，使用完畢再去掉 Qos，讓 CPU 可以進入 idle，這樣滿足了性能需求，帶來的功耗也不是特別高。

PM QoS classes framework 位于 kernel/power/qos.c 中，負責系統級別的 PM QoS 管理。per-device PM QoS framework 位于 drivers/base/power/qos.c 中，負責 per-device 的 PM QoS 管理。Common header 位于 include/linux/pm_qos.h 中，負責通用數據結構的抽象、函數聲明等工作。

在 kernel/power/qos.c 中，有 cpu_latency_qos_update_request 接口可以使用，通過該接口將 Qos 拉到 150，使用完畢再將 Qos 拉到 -1（關閉）。

使用方法：

1、文件開頭注冊自己的結構體：struct pm_qos_request my_qos_request；

2、自己驅動的 probe 函數加上：cpu_latency_qos_add_request（my_qos_request， PM_QOS_DEFAULT_VALUE）;

3、在做事情前加上：cpu_latency_qos_update_request（my_qos_request， 150）;

4、在做事情后加上：cpu_latency_qos_update_request（my_qos_request， PM_QOS_DEFAULT_VALUE）;PM_QOS_DEFAULT_VALUE 其實就是 -1

這樣在自己做事情期間，CPU 就不會進入 idle，自己模塊的性能就會好很多。如果還要更好，可以在此期間調節 CPU 頻率，但調頻帶來的功耗很高，需要自己評估。

該 patch 解決的問題：

1、中斷處理慢，可以在第一次中斷打進來后，拉 Qos，這樣自己后面的幾次中斷處理一定會快，使用完畢后，去掉 Qos。

2、i2c 傳輸慢，其中一種情況是 i2c 傳輸完畢返回時，CPU0 進入 idle，導致 i2c 中斷打不進來，這種情況，我們在調用 i2c_transfer 前后加上 cpu_latency_qos_update_request 的接口，就可以解決該問題。