zram vs zswap vs zcache终极指南：何时使用哪一个

Question

zram vs zswap vs zcache终极指南：何时使用哪一个

86

1. 他们到底是什么？它们有什么不同之处（我在下面的答案中写了我的理解）。 2. 在Zswap系统中，当一个页面从zswap被驱逐到实际的交换空间时，它是以压缩形式存储的吗？（还是在存储之前解压缩？据我所知，它仍然是压缩的，但我不能确定）。 3. Zcache目前处于什么状态？显然在3.11版本中被移除或者其他什么情况。这意味着什么？（链接：http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=96256460487387d28b8398033928e06eb9e428f7）。

- staticd

2答案2：提交信息明确说明了补丁（涉及zcache）已从3.11中删除，但将包含在主-mm树中。 - askb

2@staticd 为什么你没有接受自己的答案？它非常好！ - Léo Léopold Hertz 준영

1当一个页面从zswap（压缩交换缓存）中被驱逐出去时，它会被解压并放置在后备交换设备中，根据您提供的参考之一[https://lwn.net/Articles/537422/]... - Cbhihe

在恢复的写回过程中，zswap会对页面进行解压缩。然而，@mmin在下面指出这可能会导致服务器效率低下甚至存在安全风险！ - mwfearnley

我已经阅读了zram的后续版本，它允许作为写回缓存运行，这意味着现在它可以做到zswap所能做的。然而，我还没有完全理解它的配置方式，也不确定它是否真的适用；传统的zram行为是，在填满后开始使用基于磁盘的交换空间时，性能非常差。此外，在我的情况下，zswap的零配置特性使其成为一个明智的选择。 - thomasrutter

2个回答

4

关于第二点，zswap 在写回时似乎会对页面进行解压缩，证实了@Cbhihe的评论。 mm/zswap.c，第828行：

/*
 * Attempts to free an entry by adding a page to the swap cache,
 * decompressing the entry data into the page, and issuing a
 * bio write to write the page back to the swap device.
 * ...
 */
static int zswap_writeback_entry(struct zpool *pool, unsigned long handle)
{
    ...
    
    case ZSWAP_SWAPCACHE_NEW: /* page is locked */
        /* decompress */
        ...
        
        ret = crypto_comp_decompress(tfm, src, entry->length,
                         dst, &dlen);
        ...
        kunmap_atomic(dst);    


$ git show
commit 1573d2caf713874cfe0d1336c823d0fb548d8bed
Merge: 4cdf8db 0a86248
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Oct 11 23:59:07 2016 -0700

所以zswap在压缩的内存缓存很快被写回磁盘之前很可能会被遗忘的情况下非常有用。它不适用于具有大型、长期存在的堆栈，这些堆栈最终需要由实际的交换设备支持的应用程序。

- mnish

10我发现了zswap的一个潜在危险行为。当一个应用程序分配许多页面并向它们写入非常容易压缩的数据（比如一串零），zswap会高兴地将它们存储在内核slab内存中。然而，当某些情况触发实际的磁盘交换时，存储的数据突然会“爆发”--那些在内存中只占用“几个”千兆字节的页面上的许多零现在在磁盘上解压缩为数百个千兆字节。 - mnish

2攻击者可能会尝试在服务器上存储低熵数据。当某些东西触发交换时，服务器将会死机。 - mnish

1你向上游报告了吗？ - Ken Sharp

1写入未压缩数据的另一个缺点 - Mihail Malostanidis

当然，以尽量节省空间和时间的方式将数据以未压缩的形式存储会更好！这听起来是我们真正希望它能够做到的。我只能猜测，要实现这一点，要么涉及重写大量现有代码，要么需要一个更复杂的分配系统。 - mwfearnley

实际上，这似乎在https://lwn.net/Articles/548109/中有所涉及。Hugh Dickins说：“对页面缓存（文件）页面的压缩可能很吸引人，但文件系统开发人员似乎对zcache不太感兴趣。因此[...]也许最好从zswap开始，然后逐步添加zcache功能...” - mwfearnley

看起来，zswap提供的最大压缩比是2:1（至少在使用zbud时是如此）。https://www.kernel.org/doc/Documentation/vm/zswap.txt 尽管写入未压缩数据确实不幸，但似乎并不那么危险。 - Caesar

- staticd · Accepted Answer

这三个系统有很多内容，但没有一个简单的比较它们，更不用说解释它们了。我试图理解它，但我的头都快炸了。然后我以为我懂了，于是我试着写下来，结果我的头又炸了。（请参见实现摘要）我认为将其发布在这里会很有用，因为有许多StackExchange问题询问它们之间的成对比较。

何时使用何种系统的总结：

ZRAM：如果您在HDD/SSD上没有交换设备。
ZSWAP：如果您在HDD/SSD上有交换设备。
ZCACHE：它可以做ZSWAP所做的事情，并且还可以压缩和加速文件系统页面缓存。（它内部更复杂，仍在开发中，不在主线内核中）。

它们的实现摘要：

ZRAM 是一种基于压缩的 RAM 块设备（可用于交换空间）。
ZSWAP 是一种压缩的缓存，如果您已经有了交换空间。
ZCache 是一种特殊类型的虚拟 RAM 组件（超越性内存）的后端，可用于缓存文件系统页面或交换数据。

详细信息：

ZRAM：在RAM中创建一个块设备。当写入一个块时，该块将被压缩。当用作交换设备时，zram的优先级高于其他交换设备：被交换出去的页面首选发送到zram设备，直到它满了，然后才使用其他交换设备。
- 优点：独立于其他（物理）交换设备。当没有交换分区来扩展可用内存时，可以使用它。
- 缺点：如果存在其他交换设备（HDD/SSD），它们无法得到最佳利用。由于zram设备是独立的交换设备，一旦它满了，任何需要被交换出去的新页面都会直接发送到下一个交换设备，因此：
  1. 有真正的LRU（最近最少使用）倒置的可能性：最近被交换的数据将被发送到慢速磁盘，而很久以前被交换出去的非活动页面将保留在快速的ZRAM中
  2. 从磁盘发送和读取的数据将消耗大量带宽，因为它是未压缩的。
- 状态：合并到主线内核3.14中。一旦在系统上启用，需要一些用户空间配置来设置交换设备并使用它们。
ZSWAP：frontswap系统钩子尝试交换页面，并将zswap作为HDD/SSD交换设备的写回缓存：尝试压缩页面，如果包含难以压缩的数据，则直接写入磁盘。如果数据被压缩，则存储在zswap内存池中。如果当RAM中的总压缩页面超过一定大小时，从内存中交换出页面，则将最近最少使用（LRU）压缩页面写入磁盘，因为它不太可能很快被使用。
- 优点：非常高效地使用RAM和基于磁盘的交换。通过减少所需的写入和读取次数（数据被压缩并保存在RAM中）以及减少这些I/O操作的带宽，最小化磁盘I/O。
- 限制：它是磁盘交换系统的增强版本，因此依赖于硬盘上的交换分区。
- 状态：合并到3.11主线Linux内核中。
ZCache：它是超越内存系统的后端。超越内存提供一种类似RAM的内存，只能通过使用put和get调用以页面为单位进行访问。这与可以逐字节访问的普通内存不同。frontswap和cleancache系统钩子尝试交换和回收文件系统页面缓存，并将它们发送到超越内存后端。当使用zcache作为后端时，数据被压缩并存储在RAM中。当它填满时，压缩页面被驱逐到交换空间（另一个后端是RAMster，它在网络计算机之间共享一池RAM）。仅使用frontswap前端和
超凡记忆简介


[PATCH 0/8] zswap：压缩交换缓存
内核内存压缩
LSFMM：内核内存压缩
zswap压缩交换缓存



------