- 背景
- 現象
- 復現條件
- 原因
- 解決措施
背景
在22年進行PREEMPT-RT系統問題的除錯時，之前文章在CPU效能最佳化小記-使用火焰圖定位效能問題只是定位解決了其中一個問題，還有一個潛在的問題當時沒有續寫。然而，最近幾乎所有PREEMPT-RT產品上都出現了該問題，影響了非實時任務的CPU吞吐量，引起了大家的廣泛關注。因此，有必要對這個問題進行簡單記錄，希望對大家有所幫助。
本文只說明原因和結論，省略了問題定位流程。
現象
在PREEMPT-RT系統的某些應用場景下，即使沒有執行特定的應用程式，整個系統的CPU負載在間隔一段時間後會突然飆升幾百毫秒甚至幾秒鐘。同一型號的不同單板上的持續時間和間隔時間會有所不同。。
無論使用top還是pidstat進行觀察，只能確定system CPU使用率飆升，且相關執行緒不定，與具體執行緒無關。
復現條件
找到一臺具有良好實時性的機器，可以是PREEMPT-RT系統或是xenomai+rtnet系統，建立一個高實時任務。該任務使用raw socket週期性地向目標機器傳送廣播幀，週期可以是500us、1ms或2ms，但發幀週期必須非常準確，在目標機器上檢視CPU使用率會看到週期性飆高。
原因
該問題為PREEMPT-RT通病（至少我當前接觸到的核心從3.2到5.10均有該問題），整個系統中存在一個以上外部週期事件時就會出現，比如接收PLC傳送的週期乙太網幀、外部FPGA觸發的週期IO中斷事件、EtherCAT主站同步到從站參考時鐘後中斷收發乙太網幀等等。
由於外部週期事件（中斷）基於的時鐘源與PREEMPT-RT系統排程時鐘源不同，這兩個時鐘存在時鐘漂移，週期事件會和PREEMPT RT本身的系統排程事件發生週期交越，當兩個事件逐漸接近的時候，兩個事件都要處理，頻繁的上下文導致cpu飆高，系統實時任務的抖動會微微增大。這是PREEMPT-RT系統為了保證外部事件實時性而犧牲CPU吞吐量的機制所導致的。
解決措施
儘管沒有徹底解決的方法，但可以嘗試以下緩解措施：
- 對於單CPU核系統，系統tick無法關閉，該問題無解；
- 對於SMP多核系統，使能
CONFIG_NO_HZ_FULL，降低系統週期Tick，同時設定週期事件中斷的親和性到使能CONFIG_NO_HZ_FULL且沒有周期任務執行的CPU上來緩解。
關於Linux時鐘子系統，詳見本部落格之前的文章 linux時間子系統簡介。
下一篇文章，我們將探討由PREEMPT-RT實時機制導致的網路風暴下系統當機問題。