我对 zram + swapcached 有疑问。我知道 zram 是内存中的压缩交换，但 linux 使用它自己的内部 SwapCached 区域来存储最近的交换页面还在内存中。我有一台 512MB 的笔记本电脑，带有一个 ~128MB 的 zram 交换驱动器。
zram_stats 说：
orig_data_size: 97419264
compr_data_size: 40315919
和：
grep SwapCache /proc/meminfo
SwapCached: 90200 kB
这是否意味着我在 RAM 中拥有这些交换页面两次？第一次是压缩的，第二次是通过 Linux 的内部交换缓存功能解压缩的？
如果确实如此，那么当它在 RAM 中也有约 90MB 时，节省约 57MB 并不是很有用。
当我交换到 zram 时，我可以完全禁用 Linux 的交换缓存功能吗？或者我可以限制最大交换缓存区域吗？
答案1
简短的回答是，这不是复制；只是“不同”。
长答案是，SwapCache 实际上是从交换中拉出的页面（使用术语“交换”，无论后备存储如何，其中 zram 和 HDD 交换是后备存储的两个示例），并在需要主动访问时暂时解压缩。请记住：压缩 RAM 中的页面不能直接地访问，因为数据是压缩的，因此不可读（如果你想读取原始数据，那么就不可读）。所以它必须被存储某处当系统说“好的，现在我需要压缩缓存中的页面！”时。如果每次需要 zram 中的任何内容时都“动态”解压缩它，那么这将非常耗费 CPU，并且可能会导致整个系统速度变慢，这比从硬盘上的交换中读取更糟糕。因此，系统会保留一个缓存一些内存中的交换页面，其中“部分”由最近需要的页面定义。
另外，如果你聪明地指出，交换到硬盘的页面是不是压缩：交换缓存仍在那里使用，因为访问这些页面时不会产生较高的 CPU 开销，而是在等待 HDD 查找和获取扇区并将它们返回到内存（以便将它们添加到交换缓存）时会产生较高的延迟。
这种管理策略允许您针对启动大量程序的用例进行优化；随着内存压力的增加（zram），将一些程序的工作集推送到压缩交换中；然后，当您在前台访问该程序或者它执行某些后台活动时，将各个程序的工作集（一次一个程序）解压缩到未压缩的交换缓存中。
这与交换的一般工作方式并无太大区别，无论其后备存储是什么（RAM 或交换中的压缩缓存）。如果您的硬盘速度非常慢，并且打开了许多程序，并且使用了大量交换空间，您会注意到以下症状：
“前台”程序（您正在交互的窗口）通常表现良好现在）
加载任何长时间在后台运行的程序时，会出现长时间延迟和大量可听见的磁盘磨损声
因此，使用压缩 RAM 代替 HDD 交换的好处是，当您将后台程序移到前台时，可以避免“长时间延迟和大量可听见的磁盘磨损”。相反，CPU 会疯狂地对压缩页面进行解压缩，并在您访问程序时将它们暂时存储在交换缓存中，这样多次访问同一个压缩页面不会导致每次都进行 CPU 密集型解压缩。但就我个人而言，我更愿意拥有更高的 CPU 活动，而不是高磁盘 I/O 和随之而来的延迟。
答案2
是的，这意味着这些页面在内存中存在两次：一次压缩，一次解压缩。不，您无法禁用它。
我一直希望带有 zcache 的 frontswap 能够解决这个问题，它最终被合并到 linux 3.5 中，但看起来你仍然必须有一个真正的 swap，否则 frontswap 就无法工作。