1. 技術背景
說到壓縮這個詞，我們並不陌生，應該都能想到是降低佔用空間，使同樣的空間可以存放更多的東西，類似於我們平時常用的文件壓縮,內存壓縮同樣也是爲了節省內存。
儘管當前android手機6GB，8GB甚至12GB的機器都較爲常見了，但內存無論多大，總是會有不夠用的時候。當系統內存緊張的時候，會將文件頁丟棄或回寫回磁盤（如果是髒頁），還可能會觸發LMK殺進程進行內存回收。這些被回收的內存如果再次使用都需要重新從磁盤讀取，而這個過程涉及到較多的IO操作。就目前的技術而言，IO的速度遠遠慢於這RAM操作速度。因此，如果頻繁地做IO操作，不僅影響flash使用壽命，還嚴重影響系統性能。內存壓縮是一種讓IO過程平滑過渡的做法, 即儘量減少由於內存緊張導致的IO，提升性能。
2. 主流內存壓縮技術
目前linux內核主流的內存壓縮技術主要有3種：zSwap, zRAM, zCache。
2.1 zSwap
zSwap是在memory與flash之間的一層“cache”,當內存需要swap出去磁盤的時候，先通過壓縮放到zSwap中去，zSwap空間按需增長。達到一定程度後則會按照LRU的順序(前提是使用的內存分配方法需要支持LRU)將就最舊的page解壓寫入磁盤swap device，之後將當前的page壓縮寫入zSwap。
zswap本身存在一些缺陷或問題:
1) 如果開啓當zswap滿交換出backing store的功能, 由於需要將zswap裏的內存按LRU順序解壓再swap out, 這就要求內存分配器支持LRU功能。
2) 如果不開啓當zswap滿交換出backing store的功能, 和zRam是類似的。
2.2 zRram
zRram即壓縮的內存， 使用內存模擬block device的做法。實際不會寫到塊設備中去，只會壓縮後寫到模擬的塊設備中，其實也就是還是在RAM中，只是通過壓縮了。由於壓縮和解壓縮的速度遠比讀寫IO好，因此在移動終端設備廣泛被應用。zRam是基於RAM的block device, 一般swap priority會比較高。只有當其滿，系統纔會考慮其他的swap devices。當然這個優先級用戶可以配置。
zRram本身存在一些缺陷或問題:
1) zRam大小是可靈活配置的, 那是不是配置越大越好呢? 如果不是,配置多大是最合適的呢?
2) 使用zRam可能會在低內存場景由於頻繁的內存壓縮導致kswapd進程佔CPU高, 怎樣改善?
3) 增大了zRam配置,對系統內存碎片是否有影響?
要利用好zRam功能, 並不是簡單地配置了就OK了, 還需要對各種場景和問題都做好處理, 才能發揮最優的效果。
2.3 zCache
zCache是oracle提出的一種實現文件頁壓縮技術，也是memory與block dev之間的一層“cache”,與zswap比較接近，但zcache目前壓縮的是文件頁，而zSwap和zRAM壓縮是匿名頁。
zcache本身存在一些缺陷或問題:
1) 有些文件頁可能本身是壓縮的內容, 這時可能無法再進行壓縮了
2) zCache目前無法使用zsmalloc, 如果使用zbud,壓縮率較低
3) 使用的zbud/z3fold分配的內存是不可移動的, 需要關注內存碎片問題
3.內存壓縮主流的內存分配器
3.1 Zsmalloc
zsmalloc是爲ZRAM設計的一種內存分配器。內核已經有slub了， 爲什麼還需要zsmalloc內存分配器？這是由內存壓縮的場景和特點決定的。zsmalloc內存分配器期望在低內存的場景也能很好地工作，事實上，當需要壓縮內存進行zsmalloc內存分配時，內存一般都比較緊張且內存碎片都比較嚴重了。如果使用slub分配， 很可能由於高階內存分配不到而失敗。另外，slub也可能導致內存碎片浪費比較嚴重，最壞情況下，當對象大小略大於PAGE_SIZE/2時，每個內存頁接近一般的內存將被浪費。
Android手機實測發現，anon pages的平均壓縮比大約在1:3左右，所以compressed anon page size很多在1.2K左右。如果是Slub，爲了分配大量1.2K的內存，可能內存浪費嚴重。zsmalloc分配器嘗試將多個相同大小的對象存放在組合頁（稱爲zspage）中，這個組合頁不要求物理連續，從而提高內存的使用率。
需要注意的是, 當前zsmalloc不支持LRU功能, 舊版本內核分配的不可移動的頁, 對內存碎片影響嚴重, 但最新版本內核已經是支持分配可移動類型內存了。
3.2 Zbud
zbud是一個專門爲存儲壓縮page而設計的內存分配器。用於將2個objects存到1個單獨的page中。zbud是可以支持LRU的, 但分配的內存是不可移動的。
3.3 Z3fold
z3fold是一個較新的內存分配器, 與zbud不同的是, 將3個objects存到1個單獨的page中,也就是zbud內存利用率極限是1:2, z3fold極限是1:3。同樣z3fold是可以支持LRU的, 但分配的內存是不可移動的。
4.內存壓縮技術與內存分配器組合對比分析
結合上面zSwap / zRam /zCache的介紹, 與zsmalloc/zbud/z3fold分別怎樣組合最合適呢?
下面總結了一下, 具體原因可以看上面介紹的時候各類型的特點。
5.zRAM技術原理
本文重點介紹zRam內存壓縮技術，它是目前移動終端廣泛使用的內存壓縮技術。
5.1 軟件框架
下圖展示了內存管理大體的框架， 內存壓縮技術處於內存回收memory reclaim部分中。
再具體到zRam, 它的軟件架構可以分爲3部分， 分別是數據流操作，內存壓縮算法 ，zram驅動。
數據流操作:提供串行或者並行的壓縮和解壓操作。
內存壓縮算法：每種壓縮算法提供壓縮和解壓縮的具體實現回調接口供數據操作調用。
Zram驅動：創建一個基於ram的塊設備， 並提供IO請求處理接口。
5.2 實現原理
Zram內存壓縮技術本質上就是以時間換空間。通過CPU壓縮、解壓縮的開銷換取更大的可用內存空間。
我們主要描述清楚下面這2個問題：
1） 什麼時候會進行內存壓縮？
2） 進行內存壓縮/解壓縮的流程是怎樣的？
進行內存壓縮的時機：
1） Kswapd場景：kswapd是內核內存回收線程， 當內存watermark低於low水線時會被喚醒工作， 其到內存watermark不小於high水線。
2） Direct reclaim場景：內存分配過程進入slowpath, 進行直接行內存回收。
下面是基於4.4內核理出的內存壓縮、解壓縮流程。
內存回收過程路徑進行內存壓縮。會將非活躍鏈表的頁進行shrink, 如果是匿名頁會進行pageout, 由此進行內存壓縮存放到ZRAM中， 調用路徑如下：
在匿名頁換出到swap設備後， 訪問頁時， 產生頁訪問錯誤, 當發現“頁表項不爲空， 但頁不在內存中”， 該頁就是已換到swap區中，由此會開始將該頁從swap區中重新讀取， 如果是ZRAM， 則是解壓縮的過程。調用路徑如下：
5.3 內存壓縮算法
目前比較主流的內存算法主要爲LZ0, LZ4, ZSTD等。下面截取了幾種算法在x86機器上的表現。各算法有各自特點， 有以壓縮率高的， 有壓縮/解壓快的等， 具體要結合需求場景選擇使用。
6.zRAM技術應用
本節描述一下在使用ZRAM常遇到的一些使用或配置，調試的方法。
6.1 如何配置開啓zRAM
1） 配置內存壓縮算法
下面例子配置壓縮算法爲lz4
echo lz4 > /sys/block/zram0/comp_algorithm
2） 配置ZRAM大小
下面例子配置zram大小爲2GB
echo 2147483648 > /sys/block/zram0/disksize
3） 使能zram
mkswap /dev/zram0
swapon /dev/zram0
6.2 swappiness含義簡述
swappiness參數是內核傾向於回收匿名頁到swap（使用的ZRAM就是swap設備）的積極程度， 原生內核範圍是0~100， 參數值越大， 表示回收匿名頁到swap的比例就越大。如果配置爲0， 表示僅回收文件頁，不回收匿名頁。默認值爲60。可以通過節點“/proc/sys/vm/swappiness”配置。
6.3 zRam相關的技術指標
1） ZRAM大小及剩餘空間
Proc/meminfo中可以查看相關信息
SwapTotal：swap總大小, 如果配置爲ZRAM, 這裏就是ZRAM總大小
SwapFree：swap剩餘大小, 如果配置爲ZRAM, 這裏就是ZRAM剩餘大小
當然， 節點 /sys/block/zram0/disksize是最直接的。
2） ZRAM壓縮率
/sys/block/zram<id>/mm_stat中有壓縮前後的大小數據， 由此可以計算出實際的壓縮率
orig_data_size：壓縮前數據大小， 單位爲bytes
compr_data_size ：壓縮後數據大小， 單位爲bytes
3） 換出/換入swap區的總量, proc/vmstat中中有相關信息
pswpin:換入總量， 單位爲page
pswout:換出總量， 單位爲page
6.4 zRam相關優化
上面提到zRam的一些缺陷, 怎麼去改善呢?
1) zRam大小是可靈活配置的, 那是不是配置越大越好呢? 如果不是配置多大是最合適的呢?
zRam大小的配置比較靈活, 如果zRam配置過大, 後臺緩存了應用過多, 這也是有可能會影響前臺應用使用的流暢度。另外, zRam配置越大, 也需要關注系統的內存碎片化情。因此zRam並不是配置越大越好,具體的大小需要根據內存總大小及系統負載情況考慮及實測而定。
2) 使用zRam,可能會存在低內存場景由於頻繁的內存壓縮導致kswapd進程佔CPU高, 怎樣改善?
zRam本質就是以時間換空間, 在低內存的情況下, 肯定會比較頻繁地回收內存, 這時kswapd進程是比較活躍的, 再加上通過壓縮內存, 會更加消耗CPU資源。改善這種情況方法也比較多, 比如, 可以使用更優的壓縮算法, 區別使用場景, 後臺不影響用戶使用的場景異步進行深度內存壓縮, 與用戶體驗相關的場景同步適當減少內存壓縮, 通過增加文件頁的回收比例加快內存回收等等。
3) 增大了zRam配置,對系統內存碎片是否有影響?
使用zRam是有可能導致系統內存碎片變得更嚴重的, 特別是zsmalloc分配不支持可移動內存類型的時候。新版的內核zsmalloc已經支持可移動類型分配的， 但由於增大了zRam,結合android手機的使用特點, 仍然會有可能導致系統內存碎片較嚴重的情況,因些內存碎片問題也是需要重點關注的。解決系統內存碎片的方法也比較多, 可以結合具體的原因及場景進行優化。
參考資料：
[1] https://github.com/lz4/lz4
[2] kernel\Documentation\blockdev\zram.txt
[3] kernel\Documentation\vm\zswap.txt
[4] kernel\Documentation\sysctl\vm.txt
本文轉載自公衆號內核工匠
