1. 程式人生 > >UKSM & KSM在Android上的表現

UKSM & KSM在Android上的表現

作為一個系統管理程式(hypervisor),Linux® 有幾個創新,2.6.32 核心中一個有趣的變化是 KSM(Kernel Samepage Merging) 允許這個系統管理程式通過合併記憶體頁面來增加併發虛擬機器的數量。Linux UKSM 是國人自主研發的一個 Linux 核心相關專案,這個專案對伺服器和桌面應用都可以顯著的減少 Linux 系統冗餘的記憶體,已經在 RHEL6、CentOS 6、Ubuntu 12.04 等系統充分驗證和測試過。Linux相同頁面合併機制(KSM)使得記憶體中相同的頁面,可以通過修改頁表的方式合併成一個。通常這個機制被應用在有眾多虛擬機器(目前僅支援 KVM)或者有很多冗餘記憶體資料的場景(如有很多類似資料工作集的並行科學計算)裡面。但是,目前它的實現方式仍然比較簡陋,UKSM的出現,徹底消除了KSM原本侷限,真正使得這項技術能被更多的普通使用者使用。 眾所周知,Android 核心衍生自Linux,但因平臺特性,Android Kernel與 Linux Kernel演變出分歧,KSM和UKSM是意在解決記憶體冗餘佔用問題開發出的兩個核心模組,他們在安裝執行多個虛擬機器宿主Host上表現相當出色。尤其是UKSM,較於KSM,有較高的效能、透明度和安全性,被廣大Kernel核心開發人員和大型伺服器使用者所青睞。 我們的產品記憶體有限,合併冗餘的記憶體佔用,從記憶體優化的角度出發,KSM和UKSM無疑是比較好的選擇。以下我們針對KSM和UKSM的表現作出測試,以作為UKSM和KSM是否登入產品的決策依據。 說明:KSM在Android Kernel 3.10時代就已經整合,核心開關為 CONFIG_KSM,依賴開關為CONFIG_MMU,UKSM為國人解決伺服器冗餘記憶體佔用研發,可供參考的版本為0.1.2.3-for-v3.1 ~~~0.1.2.5-for-v3.18。

測試條件: 1.機型:(1G RAM/ MT6580); 2.平臺:Android 7.1; 3.核心:Kernel 3.18 測試步驟: 測試機在核心中整合uksm模組,對比機關閉uksm模組,開啟ksm開關,使用原生ksm模組做記憶體合併。測試機與對比機測試方法相同。正常開機開始統計資料(ksm和uksm守護程序CPU佔用、整機記憶體剩餘佔用),開機手機靜置10min,隨即開始使用native應用test.bin進行記憶體申請和填充 “test 200 1”,申請200M記憶體,整塊記憶體區域使用’1’填充,等待兩分鐘後重復申請填充,第4分鐘同上,等待2分鐘,終止資料抓取指令碼。 測試原理: 測試機器在正常執行過程中,ksm/uksm對記憶體合併的積極性、合併效率(記憶體曲線展示)以及在此過程中的cpu開銷(top資料體現)。

資料分析: 16min測試中對比機(ksm)和測試機(uksm)的記憶體波動。分析,在手機靜置的10min中,uksm合併不如ksm積極,現象是在此過程中整機記憶體uksm略少於ksm,這一值約為30~40M。分別在10min、12min和14min時由test發起的記憶體申請可以看出,uksm對此200M記憶體的合併速度遠遠快於ksm,即uksm遍歷合併完成200M記憶體耗時16s,而ksm完成此過程需要平均60s。 合併動作發生時的記憶體波動,可以直觀展示合併效率 下面是top -m 50 中的ksmd/ukamd資訊,可以看出uksm對CPU的利用率非常高,而就記憶體頁檢測而言,cpu佔用穩定在1%一下,而此資料在ksmd上為均值26%,而且整機執行過程中,ksmd的cpu佔用持續高波動,對功耗產生的壓力較大。 這裡寫圖片描述

這項資料表明,UKSM在Android上的表現確實優於KSM,無論從速度還是CPU資源消耗的角度。但是在小記憶體裝置上並沒有什麼優勢,親測:累死累活得合併10~15M記憶體,功耗上來了,犯不著費這個勁,指著大記憶體裝置上驗證是否有用,畢竟國內的牛人當初整出來UKSM就是針對虛擬機器伺服器這種使用場景。