为什么zswap在writeback时要先解压,而非直接将压缩数据写到swap设备?

[kashu]

个人观点：zswap本身就相当于一个大号的磁盘缓存，从里面换到磁盘swap的页都已经是很不常用的页了，再来个磁盘缓存保障这些很不常用的页的命中率，得到的好处比不上算法复杂度增加带来的影响。

末尾的那半话，我个人不太同意。

1）这个是我自己做的非常简单的测试，能从个人感观上感受到启动zswap后是会带来系统性能上的一个提升的（测试可能不太严谨，各位也帮我看看这测试会不会有什么问题？）
https://forum.ubuntu.org.cn/viewtopic.php?f=39&t=477670

2）下面是外国人做的测试报告，也体现了启用zswap后，相比启用之前有明显的系统性能上的提升/改善。
https://www.ibm.com/developerworks/comm ... y7?lang=en
这是对应的中文译文：http://www.csdn.net/article/a/2013-03-21/15814539

3）关于算法，我不懂所谓的复杂度到底达到了怎样一种程度，并且这种程度对CPU或整体系统来说需要耗费多少资源才能承受得起（对现今的硬件来说，是高？是低？还是可以忽略不计？）。目前来说，LZO确实是比LZ4压缩算法要慢，耗费的资源更多一点，但压缩比会更低（压缩后的数据相比LZ4更小），我个人现在选择使用了LZ4。理由是：它压缩和解压速度非常快！
这是别人的测试：
http://blog.csdn.net/zhangskd/article/details/17009111
http://blog.csdn.net/zhangskd/article/details/17283875
https://www.v2ex.com/t/87423
摘抄：

LZ4测试
Xeon E5504 @ 2.00GHz，X84_64，8核CPU，只用了一个。

(1) 速度

可以看到压缩速度和解压速度都很快，而且对日志文件的压缩比相当高。

(2) 压缩比
原始文件为linux-3.6.10.tar，大小为467MB。
用gzip压缩后为linux-3.6.10.tar.gz，大小为101MB，压缩比为21.62%。
用bzip2压缩后为linux-3.6.10.tar.bz2，大小为79MB，压缩比为16.91%。
用lz4压缩后为linux-3.6.10.tar.lz4，大小为166MB，压缩比为35.38%。
用lz4_HC压缩后为linux-3.6.10.tar.lz4，大小为117MB，压缩比为25.03%。

可以看到在压缩比上：lz4 < lz4_HC < gzip < bzip2。
然而在压缩过程中，笔者可以感觉到lz4的压缩时间比其它的要少一个数量级，几乎是瞬间完成：）
所以LZ4的优势在于压缩和解压速度，而不是压缩比。

[kashu]

如果压缩后的一个页面变大了

使用压缩算法压缩之后Page frame反而会变大，能举几个例子吗？什么情况下反而会变大？

这个不用要例子吧，任何压缩算法都不能保证对于任意输入，都能减少输入数据的体积

其实，我是想知道，zswap里面能用到的压缩算法其实是和我们日常使用的压缩软件是一样的道理
比如，在碰到一些视频文件、高压缩的图片文件、高密度的数据文件等等，再去使用压缩软件来压缩时，有时得到的结果反而更大。

是不是可以简单地说：根据文件的类型或数据的类型，那么zswap里面有时压缩后的数据会比原来的大？而前面也谈到，压缩率很差的数据会被拒绝，转而使用原数据？

[rosynirvana]

其实，我是想知道，zswap里面能用到的压缩算法其实是和我们日常使用的压缩软件是一样的道理
比如，在碰到一些视频文件、高压缩的图片文件、高密度的数据文件等等，再去使用压缩软件来压缩时，有时得到的结果反而更大。

是不是可以简单地说：根据文件的类型或数据的类型，那么zswap里面有时压缩后的数据会比原来的大？而前面也谈到，压缩率很差的数据会被拒绝，转而使用原数据？

看不出您这段话的重点是什么
压缩算法是从字节流上来进行操作的，所以实际操作中无法根据”文件的类型或数据的类型“进行推断，或者说，信息熵与内容本身无关
如果是从数学上进行一个粗略的描述，那么经过压缩的数据已经除去了（在一种算法视角下的）大多数冗余，所以用其他算法也难以压缩

[astolia]

个人观点：zswap本身就相当于一个大号的磁盘缓存，从里面换到磁盘swap的页都已经是很不常用的页了，再来个磁盘缓存保障这些很不常用的页的命中率，得到的好处比不上算法复杂度增加带来的影响。

末尾的那半话，我个人不太同意。

1）这个是我自己做的非常简单的测试，能从个人感观上感受到启动zswap后是会带来系统性能上的一个提升的（测试可能不太严谨，各位也帮我看看这测试会不会有什么问题？）

不客气地讲，你没有看懂这个帖子在讨论什么。你的测试以及你提到的其他人的测试都和讨论的东西无关，无法否定也无法支持我上面的观点。
这里没有人怀疑zswap在显著减少页交换导致的磁盘IO从而提升整体性能方面的效果，我们讨论的是当zswap的空间也不够用时，是1)直接将zswap空间中已压缩的页数据写到磁盘swap空间好还是2)先解压出来再写好。
你列出的所有链接都是在2)的情况下的结果。要想测试1)的情况，必须修改zswap的实现机制，目前还没见到有人公开发表过相关的代码。

3）关于算法，我不懂所谓的复杂度到底达到了怎样一种程度，并且这种程度对CPU或整体系统来说需要耗费多少资源才能承受得起（对现今的硬件来说，是高？是低？还是可以忽略不计？）。目前来说，LZO确实是比LZ4压缩算法要慢，耗费的资源更多一点，但压缩比会更低（压缩后的数据相比LZ4更小），我个人现在选择使用了LZ4。理由是：它压缩和解压速度非常快！

我所说的算法复杂度不是指的是zswap中使用的某个压缩算法，而是指整个zswap页交换机制的算法。如果要实现上面的1)，必然会导致zswap中需要有额外的数据结构和算法来追踪管理磁盘swap空间中的数据。

[kashu]

不客气地讲，你没有看懂这个帖子在讨论什么。你的测试以及你提到的其他人的测试都和讨论的东西无关，无法否定也无法支持我上面的观点。

谢谢指导，我完全脱节了。原来我是从使用上/实用应用上来说的我的看法了……

[科学之子]

"备用swap设备"是什么意思?指的是缓冲区?

如果压缩后页面变大了,那应该立即抛弃压缩结果,用原始数据啊,不然存在zpool里面也是浪费额外空间

备用swap设备是文档中的backing swap device，就是一个swap device

你说的是对的，压缩率很差的数据会被拒绝

zswap是frontswap的一个后端，frontswap是通过swap_writepage和swap_readpage接入内核的
如果zswap的数据已经被写入了backing swap device，frontswap向zswap查询时候会失败，swap_readpage向frontswap查询也就失败了，这时候swap_readpage会像frontswap不存在一样直接从swap device把页面信息读回来

这样做可以保持代码简单，而且保证swap_readpage效率不比原来没有frontswap的时候差

"backing swap device"此处backing翻译为"后端"也许更合适?
例如搜索"bcache backing"就会出现类似表述,bcache资料中的"backing device"在中文资料中好像就是"后端设备"
而且查词典的话,"backing"是"back"的变形
back有"后面,背后"的意思.
不一定正确,仅供参考

[rosynirvana]

"backing swap device"此处backing翻译为"后端"也许更合适?
例如搜索"bcache backing"就会出现类似表述,bcache资料中的"backing device"在中文资料中好像就是"后端设备"
而且查词典的话,"backing"是"back"的变形
back有"后面,背后"的意思.
不一定正确,仅供参考

这些词没有严格的定义，所以怎么翻译乃至怎么用在我看来无所谓

但是如果翻译成后端，同语境中经常出现
“zswap是frontswap的一个后端”
如果并列一句
“zswap的后端swap设备”
不觉得完全不正确吗