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/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手機的使用特點, 仍然會有可能導致系統內存碎片較嚴重的情況,因些內存碎片問題也是需要重點關注的。解決系統內存碎片的方法也比較多, 可以結合具體的原因及場景進行優化。