劉棟

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

雖然在Linux中，有很多開源軟件可以用來測量整個系統(tǒng)的性能，但是這些軟件同時可能也會引進其他問題，最終導(dǎo)致調(diào)試優(yōu)化過程變得更加復(fù)雜。本文將介紹德國的ADIT公司面臨的類似問題，并最終如何使用勞特巴赫的TRACE32這一非侵入式硬件跟蹤工具來解決這些問題。

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

1 Linux軟件調(diào)試的挑戰(zhàn)

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

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

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

2 TRACE32 PowerTrace硬件跟蹤效果

因此，ADIT決定使用TRACE32PowerTrace的硬件跟蹤功能，該跟蹤功能不會對目標(biāo)系統(tǒng)的時序有任何影響，同時也允許使用者對最小代碼部分進行深入分析。

Arm和Intel設(shè)備都能提供非侵入式的程序流信息，Arm的這種技術(shù)是ETM（嵌入式跟蹤宏單元）Intel相應(yīng)的技術(shù)則是IPT（Intel處理器跟蹤）。代碼的執(zhí)行信息會通過一系列專用的引腳傳輸出來。TRACE32工具連上這些引腳后，無需修改客戶任何程序代碼，就能夠?qū)崟r收集數(shù)據(jù)并分析，以此產(chǎn)生應(yīng)用程序的函數(shù)流和每個函數(shù)的詳細時序。

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

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

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

3結(jié)論

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