巧妇能为少米之炊（3）——压缩饼干（ZRAM）

知道了压缩与解压的算法，页面到底是怎么被压缩，它的一个流程是怎么样的呢？一切都要回到zram的块设备驱动。

         设备驱动文件路径：LINUX/android/kernel/drivers/staging/zram/zram_drv.c

         众所周知，zram是可随机存储的设备，它不同于磁盘需要考虑IO调度的问题，所以在编写zram的设备驱动的时候，选择不是默认的request_queue，而是自定义了一个“请求制造函数”：

zram->queue = blk_alloc_queue(GFP_KERNEL);

blk_queue_make_request(zram->queue, zram_make_request);

blk_queue_make_request函数将申请的队列，与函数zram_make_request联系起来，在有IO数据产生的时候，就会调用zram_make_request这个函数。

    在块数据传输的过程中，除了request_queue ，struct bio 也是一个非常重要的数据结构，zram_make_request会遍历struct bio，根据参数rw的值，判断是要zram中读出数据，还是往zram中写入数据，所以压缩和解压的函数就在这里被调用。

    当判断出是往zram中写入数据的时候，会调用：

ret =zram_bvec_write(zram,bvec, index, offset);

if (unlikely(!meta->table[index].handle) ||
	zram_test_flag(meta, index, ZRAM_ZERO)) {

		handle_zero_page(bvec);		//处理零页面
		return 0;
	}

如果不是零页面，函数就会对解压后的页面做一个临时内核映射，保证解压后的页面能正确写入内存。

    随后就是真正开始解压缩的过程，解压缩函数为：zram_decompress_page，但是这个函数并不是真正只是完成解压缩的功能，它会做一些解压缩前的工作，如做一些映射，读出将要解压的页面数据，再进行一些判断，真正解压缩的工作由函数

lzo1x_decompress_safe完成，该函数位于LINUX/android/kernel/lib/lzo/lzo1x_decompress.c中调用语句为：

ret =lzo1x_decompress_safe(cmem,meta->table[index].size,mem, &clen);

最后解压出的数据，存在mem指针所在内存中，meta->table[index].size是压缩数据的大小，而cmem则是解压前的数据，

Clen为解压后的大小。

那么压缩过程又是咋样的呢？通过阅读zram_bvec_write的源代码，发现它也调用了zram_decompress_page这个函数，这是怎么回事？为什么压缩过程会调用解压函数呢？代码的注释解释为：即使不完整页面的IO传输，也需要读取整个页面。细细查看，发现zram_decompress_page中有这样几条语句：

if (meta->table[index].size == PAGE_SIZE)
		copy_page(mem, cmem);
	else
		ret = lzo1x_decompress_safe(cmem, meta->table[index].size, mem, &clen);

当判断所要解压的页面大小等于PAGE_SIZE的时候，只是简单的拷贝页面而不是解压它，这就是在压缩之前调用zram_decompress_page的原因。

         在进行了一系列的处理之后，如零页面处理，最后调用了：

ret =lzo1x_1_compress(uncmem,PAGE_SIZE,src, &clen,meta->compress_workmem);

uncmem是压缩前的指针地址，src则是压缩后的数据指针，clen是压缩后的长度。而src在初始的时候被赋值：

src =meta->compress_buffer;即一开始就设置了压缩的缓冲区。

     得到了压缩后的数据和长度，接下来的任务并不是写入到压缩页面中，而是判断压缩后的数据是不是比PAGE_SIZE大，一般来说，压缩之后的大小小于PAGE_SIZE/2，则称为“瘦压缩”，大于PAGE_SIZE/2的称为“胖压缩”，大于PAGE_SIZE的称为“坏压缩”，如果出现了坏压缩，则调用am->stats.bad_compress++;说明此页面没有也所的必要了，所以存入zram的是原来的页面，出现了“瘦压缩”，则调用zram->stats.good_compress++;说明这个压缩是成功的，内存总是希望越多的“瘦压缩”越好，而事实情况下，一般都是一个“胖压缩”与一个“瘦压缩”共用一个页面，如果压缩密度过高，则解压的过程也会非常耗时，这会影响系统的总体性能。

     正常压缩的情况下，去的压缩页面数据后，存入页面即可，最后更新zram数据结构中需要保存的数据，还有解除一些内存映射就完成了压缩的过程。

还有什么能改进？

因为zram已经成熟了很多年，也一直被使用，又一次逛github，发现有人竟然用LZ4算法代替了LZO压缩算法，这真的试一次改进，后来成功移植之后，我个人没有感觉到明显的提升，理论上，LZ4的解压速度是LZO的3倍以上，但是由于内存自己解压和压缩的速度已经非常快了，所以感觉提升不明显，但是建议各位可以尝试着改变一下，毕竟科技日新月异，以后是否需要更大的数据呢？如果一个文件解压需要3分钟，和一个文件解压需要1分钟，这时候区别就出来了，笔者也尝试着将Linux内核用LZ4压缩和解压，经过试验，提升都不明显，但是很期待LZ4在以后的表现，也期待有更多优秀的算法出来。