FreeBSD 现在能在 25 毫秒内完成启动 | Linux 中国

这是运行在 AWS Firecracker 上的，当然，同时也有其他的新兴微虚拟机(microVM)引擎可供选择。

在更换了 FreeBSD 内核中的排序算法后，其启动速度提高了 100 倍以上……虽然这是专门针对 微虚拟机(microVM) 的优化，但所有人都应能从中受益。

过去五年，微虚拟机在科技研发领域中备受关注。其核心理念是重新包装和创新了 IBM 在 1960 年代随着 虚拟机管理程序(hypervisor) 诞生所发明的 一些概念和技术🔗 www.theregister.com：设计专门作为另一个操作系统上的访客系统运行的操作系统。这意味着该操作系统必须专门构建在虚拟机内执行，并与特定的管理程序提供的资源进行交互，而不是模拟硬件。

这就意味着访客操作系统几乎不需要针对真实硬件的支持，只需要 VirtIO🔗 wiki.osdev.org 驱动，它们可以直接和宿主机的管理程序提供的功能进行交互。反过来说，管理程序无需提供模拟的 PCI 总线、模拟的电源管理、模拟的显卡、模拟的网卡等等。结果就是，管理程序本身可以变得更加微型和简化。

通过无情地缩减虚拟机监视器和运行在其内部的操作系统，这让两端都能更小、更简洁。意味着虚拟机能更少的使用资源，并能更快速地启动。

目前，这个商业目标是提供 “无服务器(serverless)” 的计算能力。实际上，“无服务器” 是一种市场双关语：当然，真实世界中的服务器仍存在于某个数据中心中。但这与提供“基础设施即服务（IaaS）”模型不同，而是提供“函数即服务（FaaS）🔗 www.theregister.com”的模式。这就代表着你不需要了解任何有关基础设施的知识 —— 你的程序直接调用另一个程序，然后管理工具会运行所需的特定操作，返回结果，然后删除用于执行计算的虚拟机。你根本不需要知道这过程在何处，如何进行。

对消费者来说，这种技术的优势在于其快速和易用性。而对服务提供商而言，因为能够更快地回收和再利用资源，使得相同的硬件能服务更多的客户，这是一个巨大的优势。

AWS 通过一项名为 Lambda 的服务提供 FaaS，这个名称是来源于一个深奥的函数式编程术语。Lambda 由亚马逊自家研发的 Firecracker🔗 www.theregister.com 管理程序提供支持，Firecracker 同样也支撑着 Fargate🔗 www.theregister.com 这一无服务器服务。

Firecracker 基于 Linux 内核的内建 KVM 管理程序：这本身就有别于之前 AWS 基于 Xen 管理程序🔗 www.theregister.com 的实践。这也就意味着它本质上是一个 Linux-on-Linux 的解决方案。这听起来对 FreeBSD 内核开发者 Colin Percival 来说像是一个挑战，正如我们 一年前的报道🔗 www.theregister.com：他决定在 Firecracker 上运行 FreeBSD。然而就如同大部分的计算任务一样，优化的过程大致上是：首先，让它可以运行；然后，提高其运行速度。

根据他本周稍早的一则 推文🔗 twitter.com，他最新的性能优化成果相当令人震惊：替换排序算法使 FreeBSD 内核启动过程加速了约一百倍，将内核加载时间降至了惊人的 25 毫秒。换言之，只有四十分之一秒的时间。

FreeBSD（HEAD）现已不再执行其 SYSINIT 上的冒泡排序。如今，我们运行的是更高效、速度大概快了 100 倍的归并排序：https://cgit.freebsd.org/src/commit/?id=9a7add6d01f3c5f7eba811e794cf860d2bce131d

当 FreeBSD 内核在 Firecracker （配备 1 CPU，128 MB 内存）中启动时，现在有大约 7% 的时间用于执行其 SYSINIT 上的冒泡排序。

当你需要对上千个条目进行排序时，O(N^2) 的复杂度可能会带来较大的影响。因此，是时候将冒泡排序替换为更高效的算法了。

这一调整只是一系列优化措施中的最新一个环节，两天后，他进一步 详细🔗 www.usenix.org 阐述了这些优化。这包括了引导所需的初始更改：消除了假定在 Xen 下引导的一些初始化步骤，然后查询 ACPI 获取处理器的类型和数量。这一步出现了问题，因为 Firecracker 并未提供 ACPI。接着，对其仿真的唯一的硬件，串行控制台，进行初始化也失败了。

这个微调只是长期进行的一系列优化中的最新一环。几天后，他更详细地描述了这些更改。这些更改描述了让系统启动所需的初步改动：移除了假定在 Xen 下引导的几个初始化步骤，然后尝试向 ACPI 查询处理器的类型和数量。然而，该尝试失败了，因为 Firecracker 并不提供 ACPI。接着，初始化它确实模拟的少量硬件之一——串行控制台——也失败了。

在内核成功启动之后，内存的使用迅速成为了一个问题：Firecracker 默认只给客户端分配了 128MB 的内存，原因在于一个必须修改的假设。之后是一整套的优化清单，每一项都为减少时间作出了一部分贡献。

即便你不是特别懂技术，阅读这篇文章也会很有趣。一些步骤更改了在专用硬件上引导的合理选择，在虚拟环境中，这些选择在机器产生、做工作、然后在几秒钟内再次被删除的情况下，已经无法适用。

Percival 评论🔗 news.ycombinator.com 称：

我相信在相同的环境下，Linux 的引导时间是 75-80 毫秒，而我已经让 FreeBSD 在 25 毫秒内引导。

他 接着🔗 news.ycombinator.com 说道：

当我开始研究提速引导的过程时，内核大约需要 10 秒钟的时间来引导，所以现在我拥有的内核引导速度，比我几年前快约 400 倍。

目前，已经优化的系统内核是 FreeBSD 14 版的，运行在 x86-64 架构上，但也正在进行适配到 Arm64 的工作 —— AWS 是世界上 最大的 Arm 服务器用户🔗 www.theregister.com。

Firecracker 是众多备受瞩目的微虚拟机中的一员，但也有其他的微虚拟机，而且它的成功也激励了 QEMU 开发者增加了一个 微虚拟机🔗 qemu.readthedocs.io 平台。Canonical 的开发者 Christian Erhardt 在 博客🔗 cpaelzer.github.io 上介绍了如何在 Ubuntu 中使用这种技术，并且在线代码开发环境供应商 Hocus 最近 解释🔗 hocus.dev 了为什么它从 Firecracker 转移到了 QEMU 等价物。

我们可以看到微虚拟机有很多潜在的使用场景，不仅仅是在云场景中。能够在一个完全不同的 OS 上运行为另一个 OS 构建的单个程序，而不需要始终运行完整的模拟环境，可能在各种情况下都非常方便。

容器是一个非常有用的工具，但在容器中你只能运行与宿主 OS 相同的二进制文件。运行任何其他的东西 —— 比如在 macOS 上运行 Docker Linux 容器 —— 意味着有一些模拟和一个访客操作系统被隐藏在堆栈的某个位置。这个 VM 能够越小，并且使用的资源越少，无论是对容器还是整个机器的整体性能来说都会更好。

（题图：MJ/a5910e84-656d-4a5c-abad-bb0b0ffcb3fc）