基于硬件跟蹤的Linux系統性能優(yōu)化

　　作者/劉棟(勞特巴赫(蘇州)技術(shù)有限公司，江蘇 蘇州 215021)

　　摘要：隨著(zhù)Linux系統的復雜度越來(lái)越高，如何調試并優(yōu)化系統性能，以提高系統硬件的使用效率，減輕系統負載也越來(lái)越重要。其關(guān)系到整個(gè)產(chǎn)品的成本和使用體驗，甚至影響產(chǎn)品上市期限。

　　雖然在Linux中，有很多開(kāi)源軟件可以用來(lái)測量整個(gè)系統的性能，但是這些軟件同時(shí)可能也會(huì )引進(jìn)其他問(wèn)題，最終導致調試優(yōu)化過(guò)程變得更加復雜。本文將介紹德國的ADIT公司面臨的類(lèi)似問(wèn)題，并最終如何使用勞特巴赫的TRACE32這一非侵入式硬件跟蹤工具來(lái)解決這些問(wèn)題。

　　關(guān)鍵詞：硬件跟蹤;調試;Linux

　　1 Linux軟件調試的挑戰

　　德國ADIT(Advanced Driver Information Technology GmbH)的最初方案是在A(yíng)rm和Intel平臺上均部署Linux，使用SystemTap來(lái)測量整體系統性能以定位并消除性能瓶頸。SystemTap使用了Linux的一些很好的功能：uprobe和kprobe。這些功能允許用戶(hù)創(chuàng )建一個(gè)動(dòng)態(tài)的跟蹤過(guò)程，可以分別跟蹤用戶(hù)級別和內核級別的函數。

　　借助工具來(lái)減輕系統負載這個(gè)理念本身并沒(méi)有問(wèn)題，而且ADIT一開(kāi)始也期望諸如SystemTap等軟件工具僅對整體系統的實(shí)時(shí)性能產(chǎn)生較小的影響。然而出乎意料的是，使用了這些軟件后，Arm平臺相較于Intel平臺而言，其系統速度的下降幅度明顯大于后者。為了確認問(wèn)題所在，ADIT創(chuàng )建了一個(gè)空函數，并且通過(guò)uprobe來(lái)進(jìn)行測量。結果表明，在A(yíng)rm平臺上，調用一次uprobe耗費的時(shí)間是Intel平臺的兩倍。因為uprobe內部使用了kprobe，所以最初的懷疑是kprobe導致了前述問(wèn)題。然而這種懷疑是錯誤的，因為實(shí)際上kprobe在A(yíng)rm處理器上比在Intel處理器上運行得更快，所以很顯然問(wèn)題出在uprobe代碼中。既然問(wèn)題出在軟件跟蹤工具的代碼中，那么軟件跟蹤工具就不適合用來(lái)解決定位問(wèn)題。

　　“因為內核uprobe代碼并不簡(jiǎn)單，一時(shí)間我不知道該如何繼續。于是我決定使用TRACE32來(lái)對之前的問(wèn)題一探究竟。有些時(shí)候，圖像是很有幫助的?；趫D表，我可以選擇部分區域的代碼來(lái)做更深層次的分析?！盇DIT的開(kāi)發(fā)者Frederic Berat說(shuō)道。

　　2 TRACE32 PowerTrace硬件跟蹤效果

　　因此，ADIT決定使用TRACE32 PowerTrace的硬件跟蹤功能，該跟蹤功能不會(huì )對目標系統的時(shí)序有任何影響，同時(shí)也允許使用者對最小代碼部分進(jìn)行深入分析。

　　Arm和Intel設備都能提供非侵入式的程序流信息，Arm的這種技術(shù)是ETM(嵌入式跟蹤宏單元)，Intel相應的技術(shù)則是IPT(Intel處理器跟蹤)。代碼的執行信息會(huì )通過(guò)一系列專(zhuān)用的引腳傳輸出來(lái)。TRACE32工具連上這些引腳后，無(wú)需修改客戶(hù)任何程序代碼，就能夠實(shí)時(shí)收集數據并分析，以此產(chǎn)生應用程序的函數流和每個(gè)函數的詳細時(shí)序。

　　ADIT的工程師在他們當前的系統狀態(tài)下，直接連接TRACE32硬件后(如圖1)，僅需在TRACE32軟件的TPIU配置窗口對PortSize和PortMode進(jìn)行適當選擇(如圖2)，即可獲取實(shí)時(shí)的跟蹤數據。整個(gè)系統的函數流都會(huì )被TRACE32軟件重建并以統計的方式進(jìn)行展現，例如時(shí)序圖或函數層級圖。最終匯總成的這張圖表，還原出了一個(gè)完整的Linux系統的運行過(guò)程，不僅包含內核代碼也包含用戶(hù)代碼。根據這張圖表，ADIT的工程師們方便地定位到系統時(shí)間消耗的關(guān)鍵函數。同時(shí)他們也注意到開(kāi)源性能測試軟件kprobe和uprobe給整個(gè)系統帶來(lái)的性能瓶頸。

　　通過(guò)使用TRACE32的高級分析特性，ADIT的工程師們快速地定位出兩個(gè)明顯的問(wèn)題點(diǎn)(見(jiàn)圖3和圖4)。最明顯的一個(gè)瓶頸，就是在A(yíng)rm平臺，uprobe調用了preempt_disable()和preempt_enable()共四次，每一次都需要耗時(shí)0.6μs檢查棧幀。這樣一共導致了2.4μs的遲延。但這個(gè)現象在Intel平臺上并不會(huì )出現。雖然單次調用uprobe引起的2.4μs遲延似乎并不是很長(cháng)，但因為每秒都調用了很多次，這部分延遲會(huì )迅速累積成嚴重的滯后。再進(jìn)一步，第二個(gè)瓶頸是uprobe調用過(guò)程中的字符串操作。并且，受制于A(yíng)rm和Intel之間的架構差異，這個(gè)瓶頸時(shí)間并不固定。

　　如果沒(méi)有實(shí)時(shí)跟蹤功能，這些瓶頸就幾乎很難被發(fā)現。而有了實(shí)時(shí)跟蹤功能后，把這些信息跟蹤并記錄下就很簡(jiǎn)單。明確了從何處著(zhù)手調查，通過(guò)對跟蹤結果的分析，ADIT的工程師確認主要問(wèn)題在于內核配置。在跨平臺遷移過(guò)程中，CONFIG_PREEMPT_TRACE這個(gè)配置項被無(wú)意地使用了。跟蹤結果顯示，這個(gè)配置被打開(kāi)后，在A(yíng)rm平臺會(huì )導致棧展開(kāi)，但在Intel平臺并沒(méi)有影響，而正是這導致了兩個(gè)平臺之間明顯的性能差異。

　　3 結論

　　通過(guò)本文案例可以看出，在Linux系統性能分析和優(yōu)化過(guò)程中，基于硬件的非侵入式實(shí)時(shí)跟蹤技術(shù)，不僅可以實(shí)現開(kāi)源跟蹤軟件的所有功能，而且也可以對Boot相關(guān)的代碼進(jìn)行跟蹤分析，同時(shí)還避免引進(jìn)一些其他問(wèn)題，并且統計結果更準確、數據分析形式更靈活。

本文來(lái)源于科技期刊《電子產(chǎn)品世界》2019年第3期第27頁(yè)，歡迎您寫(xiě)論文時(shí)引用，并注明出處