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

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

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

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

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

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

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

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

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

　　2 TRACE32 PowerTrace硬件跟蹤效果

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

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

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

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

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

　　3 結(jié)論

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

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