LWN：云上的休眠！

关注了就能看到更多这么棒的文章哦～

Hibernation in the cloud

By Jonathan Corbet 

May 25, 2020 

OSPM

Hibernation（休眠）通常被认为是笔记本电脑专用的功能，而且是老旧过时的笔记本电脑才会用的功能。人们通常不认为它与云服务环境有关。但是，在2020年Linux内核中的电源管理和调度峰会(OSPM)上，Andrea Righi提出，如果能让hibernation可靠地工作，那么在云系统上可能真的有一席之地。

hibernation的核心思想是彻底关闭系统，但在系统启动时会自动将其恢复到hibernation之前的状态，连当时正在运行的进程也恢复好。要做到这一点，就必须在关机前将内存中即将丢失的内容写入persistent storage来避免数据丢失。hibernation的优点是系统可以在不需要供电的情况下长久保留状态，代价是在hibernation和恢复时都会新增大量的I/O操作。

hibernation在2004年的时候是一个热门话题，当时它通常被称为 "software suspend"；参见LWN内核索引条目中的software suspend词条，就能明白它当时有多热门。不过在2008年左右，当suspend-to-RAM功能(通常被称为 "suspend")开始广泛使用时，hibernation的相关开发就停滞了下来。在Ubuntu 12.04中完全放弃了对hibernation的支持。Fedora 29版本中包含了一个试验性的suspend-then-hibernate功能，但 "didn't go well"，因此后来也被弃用了。他指出，现在hibernation大多时候已经没什么人提起了。

因此，当人们看到亚马逊在2018年底增加了对休眠EC2实例的支持的时候，感到非常意外。Hibernation突然就来到了云端，这与之前看到的应用场景非常不一样。Amazon的应用场景里面是希望用hibernation来暂停workload以节省成本。例如，亚马逊的 "spot instance "的优先级很低，等待空余资源。这样只要有个十分钟的提前通知，就可以把它关闭掉。这样做虽然不是很好，不过"一分钱一分货"。这是一个hibernation可以有帮助的场景。当这个instance被关闭时，它不用直接丢失所有内容了，而是可以hibernate，然后在资源再次可用时恢复工作。

How it works

Hibernation的工作原理是将内存内容写入磁盘上的 "hibernation image"镜像，此镜像会比系统中的RAM大小要小一些。数据在写入磁盘的过程中可以被压缩，并且那些可以恢复出来的page（主要是页面缓存中干净的、来自文件内容并且未被修改过数据）可以直接丢掉。Rafael Wysocki补充说，hibernation的设计是假设用户用到的大多数数据都会被swap出去了。这样一来需要备份的数据量将少于RAM size的50%。在下一次启动时，内核会检查那个计划用来恢复的映像文件，如果发现签名有效，就会把映像恢复到内存中去。然后，会用一些架构相关的特殊代码来跳转回到当初的kernel状态，这样系统就会恢复到之前的时刻然后继续执行了。

他认为，hibernation最大的问题是它是否可靠。可能没有办法100%确保可靠，系统中的各个设备，如果状态不太正常的话，都可能会导致进入hibernation的过程失败。对于hibernation过程本身来说这并不是一个大问题，因为数据都还在，尚未丢失。但是你要是非常依赖hibernation机制的话，肯定不会满意的。并且这些外设也可能会导致恢复过程出错，这样麻烦就更大了。此外kernel也有可能在休眠或resume的时候发现内存不够用了，这样整个功能就没法正常运作了。

除此之外，尽管这段代码已经有很长的历史了，但仍然有bug存在。Righi提到有一个bug在2019年底刚被修复。并且这也有security方面的影响，因为hibernation镜像在persistent storage里面保存了敏感数据。此外内存和磁盘速度可能也是个问题。他帮助过一位客户，当时看到有hibernation有超时。后来发现，他们运行在一个存储速度较慢的[Andrea Righi]instance（虚拟机）上，而timeout超时值的设置对这台机器并不合适。此外，也可能出现要保存的RAM没法塞在hibernation镜像里的问题。

他认为调试hibernation问题在任何场景下都是一个特殊的挑战，在云环境下可能更糟，尤其是你很可能无权控制hypervisor程序。

提高hibernation的可靠性，在很大程度上依赖于要使用更好的硬件设备。在这里，云场景可能具有优势，因为无论实例在哪里运行，"硬件"往往是统一的。在存储映像文件的时候，内存使用量能越小越好，这样的话就不应该使用stacked block device。内核代码应该避免在hibernation和resume过程中进行大块memory的allocation。

性能（以hibernation时间来衡量）可以通过减小hibernation镜像的大小来提高，这是通过调整/sys/power/image_{size来实现的}。更小的image_{size会导致更多的可恢复内存被丢弃}，从而减少所需的I/O量，但代价是恢复后文件缓存里面有用的数据就更少。增大image size则有效果相反，hibernation需要更长的时间，但系统恢复后会程序能更快地运行起来。

还有个技巧，就是在恢复系统后执行swapoff，这样可以强制将swap区的所有数据恢复到RAM中。这样系统可以很少浪费时间来进行paging操作，尽快恢复到全速运转。但是swapoff调用却总是很慢，这是因为swap代码在将数据送回RAM时没有正确使用readahead。现在在linux-next中已经有了这个问题的fix。Wysocki说，内核可以直接在resume时自动完成这个swapping in的动作，这是一个更好的解决方案。

对于未来的计划，Righi说，内核可以在空闲的时候进行opportunistic swapping（就是更加积极地进行预测和swap）；这样可以把更多的数据放到persistent storage中，从而加快hibernation的速度。他已经在这方面尝试了一些hack的改动，有效果，但他希望有更好的解决方案。最后，他说，hibernation可以为基于云的系统带来一些真正的好处，但必须要先解决可靠性问题。

Rafael responds

Righi说完之后，Wysocki就接下来讲述了。他说他想回应Righi的几个观点。他同意hibernation目前用的不多，但其实他自己目前也在桌面系统上在使用（这个环境没有电池）。自2016年以来，他没有看到过一次故障。也就是说，整个系统的设计都是围绕着hibernation和resume会发生在同一台机器上的假设而设计的。甚至可以说，他对于hibernation能在cloud instance环境里面也用起来，感到非常意外。

他承认x86 hibernation代码中有很多很麻烦的bug，但其中大部分在2016年得到了修复。架构代码中的hibernation功能是挺可靠的了，但一些驱动程序仍然存在问题。不过现在大多数驱动都支持suspend，hibernation的支持一般都是基于suspend的，所以能支持hibernation的设备也非常广泛。他试过的大部分笔记本都可以开箱即用，没有出现问题，不过他承认自己没有做过大量的测试。

他重复说，他认为问题很可能出在这个场景里resume的机器可能是同之前进行hibernation的机器并不是同一台。按理来说，hypervisor提供的hardware emulation应该能保证系统基本相同，但他强调这里 "没有任何保证"。

Hibernationh支持的真正麻烦是在于它给memory-management subsystem带来了太大的压力。它迫使数据都换出到swap分区（或文件）去，采用的方法是把系统中所有memory都分配掉，同时也关闭了out-of-memory killer功能。这种情况下确实可能会出现一些奇怪现象，但是从内存管理开发人员的角度来看，这是一个不起眼的corner case，所以没有引起他们足够重视来优先改进这个地方。

关于安全问题，他说，如果云提供商要提供hibernation功能，他们就得负责对hibernation镜像文件进行加密，以及其他一些安全措施。试图在内核中加入加密功能的做法，却遭到了 "security people "的反对，他们不喜欢在这里实现一个重复功能。还有，不知道应该用什么方法来把镜像加密的密钥传递给用来做resume操作的kernel，这并不是一件容易的事情。所以，这里还是有一些挑战要面对的。

就这样，会议结束了，同时2020年的OSPM也落下了帷幕。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～