我不知道我是否遗漏了什么，但请持保留态度。
因此，zram 用于通过内存交换来减少磁盘上的 I/O 操作，从而消除使用 HDD 的用户的系统冻结，并“增加”可以放在内存上的数据量。但缺点是，一旦用完此交换，您将失去速度优势，并且必须正常交换到 HDD，这也可能交换活动页面，而不是发送 LRU（最近最少使用）数据。所以它只是盲目地工作，试图压缩扔给它的所有东西。
然而，zswap 试图变得更聪明，它可以做 zram 所做的事情，但需要更多的 I/O 活动。它缓存要交换的页面，一旦内存池已满，它就会交换最近最少使用的页面。但它将不可压缩的数据直接发送到磁盘交换。
现在问题来了，听我说完。增加 zswap 的内存池大小不会使其等同于 zram，通过允许 RAM 池压缩更多数据并能够在耗尽之前接受更多页面，同时向 RAM 添加更多可用空间，同时保持智能特性zswap 之类的磁盘缓存和交换 LRU 页面？这不是两全其美吗？
唯一的缺点是它仍然会将不可压缩的数据发送到磁盘，从而导致磁盘活动。我对此不确定，但是将 swappiness 降低到 1 不会解决这个问题吗？或者交换是否只影响非活动页面，而不影响 zswap 无法压缩的页面？如果是这样，有人可以建议解决这个问题吗？
答案1
Swappiness 影响整个交换机制，因此将其设置为 1 将影响系统整体发送页面进行交换的方式。 Zswap 是常规 RAM 和交换设备之间的一层，因此如果启用 zswap，则交换只会影响系统将页面发送到 zswap 的频率。它绝对不会影响 zswap 的写回。它甚至没有意识到这一点。
设置max_pool_percent得更高确实会为 RAM 中存储更多数据腾出空间，但这与disksize在 zram 中设置更大的值没有什么不同。它具有相同的效果，如果设置得太高，可能会产生同样严重的后果。将其设置为 100 并强制您的系统进行交换，看看我的意思。
如果你真的想两全其美，那么你所需要的就是两全其美。我在启用写回的 zram 交换设备前面放置了 zswap，另外还有一个优先级较低的常规磁盘交换设备，以防万一。 Zswap 拥有所有优点，但最大压缩比为 3:1。当 zswap 触发它自己的写回时，无论是 LRU 还是不可压缩数据，该数据都会发送到 zram。如果它是不可压缩的——一个简单的脚本会触发大页面写回zram backing_dev，如果页面被LRU驱逐，那么zswap在驱逐之前解压缩它们，zram在存储之前再次压缩它们，实现比zswap更高的压缩比（使用lzo或zstd，我更喜欢zstd，它提供约 5:1 的压缩比）。相同的脚本监视 zram 消耗了多少 RAM，backing_dev如果消耗量高于所需值（我将其设置为 zswap 的 30% max_pool_percent），则将全部内容转储到 zram 中。这样，一旦系统开始交换，zswap 就会减轻最初的性能影响，而一旦满了，基于磁盘的交换不会使性能陷入停滞，而是 zram 会受到影响。即使输入到 zram 的数据无法压缩，zram 仍会在发送到 之前从中删除零填充和相同填充的页面backing_dev，从而导致更少的磁盘 i\o。令人惊讶的是，zswap 本身并没有这样做——一旦达到池限制，它就会停止接受任何新页面，因此所有零填充和相同填充的页面都将被写入磁盘，从而减慢 i\o ，并且霸占cpu。因此就有了 zram 层。