實(shí)例分析

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

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

抓 trace 分析

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

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

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

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

PM QoS classes framework 位于 kernel/power/qos.c 中，負(fù)責(zé)系統(tǒng)級別的 PM QoS 管理。per-device PM QoS framework 位于 drivers/base/power/qos.c 中，負(fù)責(zé) per-device 的 PM QoS 管理。Common header 位于 include/linux/pm_qos.h 中，負(fù)責(zé)通用數(shù)據(jù)結(jié)構(gòu)的抽象、函數(shù)聲明等工作。

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

使用方法：

1、文件開頭注冊自己的結(jié)構(gòu)體：struct pm_qos_request my_qos_request；

2、自己驅(qū)動的 probe 函數(shù)加上：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 其實(shí)就是 -1

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

該 patch 解決的問題：

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

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