FreeBSD 现在能在 25 毫秒内完成启动
微虚拟机 FreeBSD

> 
> 这是运行在 AWS Firecracker 上的，当然，同时也有其他的新兴微<ruby> 虚拟机 <rp>  （ </rp> <rt>  microVM </rt> <rp>  ） </rp></ruby>引擎可供选择。
> 
> 
> 


![](/data/attachment/album/202308/31/162750z9mduhkks254zsdd.jpg)


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


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


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


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


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


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


AWS 通过一项名为 Lambda 的服务提供 FaaS，这个名称是来源于一个深奥的函数式编程术语。Lambda 由亚马逊自家研发的 [Firecracker](https://www.theregister.com/2018/11/27/aws_sets_firecracker/) 管理程序提供支持，Firecracker 同样也支撑着 [Fargate](https://www.theregister.com/2020/04/09/aws_revamps_fargate_serverless_containers/) 这一无服务器服务。


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


根据他本周稍早的一则 [推文](https://twitter.com/cperciva/status/1693127769901969772)，他最新的性能优化成果相当令人震惊：替换排序算法使 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)` 的复杂度可能会带来较大的影响。因此，是时候将冒泡排序替换为更高效的算法了。
> > 
> > 
> > 
> 
> 
> 


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


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


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


Percival [评论](https://news.ycombinator.com/item?id=37205578) 称：



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


他 [接着](https://news.ycombinator.com/item?id=37205475) 说道：



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


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


Firecracker 是众多备受瞩目的微虚拟机中的一员，但也有其他的微虚拟机，而且它的成功也激励了 QEMU 开发者增加了一个 [微虚拟机](https://qemu.readthedocs.io/en/v8.1.0/system/i386/microvm.html) 平台。Canonical 的开发者 Christian Erhardt 在 [博客](https://cpaelzer.github.io/blogs/009-microvm-in-ubuntu/) 上介绍了如何在 Ubuntu 中使用这种技术，并且在线代码开发环境供应商 Hocus 最近 [解释](https://hocus.dev/blog/qemu-vs-firecracker/) 了为什么它从 Firecracker 转移到了 QEMU 等价物。


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


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


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




---


via: <https://www.theregister.com/2023/08/29/freebsd_boots_in_25ms/> 


作者：[Liam Proven](https://www.theregister.com/Author/Liam-Proven) 译者：ChatGPT 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](/article-16144-1.html) 荣誉推出


OK
This article is more than **1 year old**

# FreeBSD can now boot in 25 milliseconds

## On AWS Firecracker – but there are other new micro-VM engines around, too

Replacing a sort algorithm in the FreeBSD kernel has improved its boot speed by a factor of 100 or more… and although it's aimed at a micro-VM, the gains should benefit everyone.

MicroVMs are a hot area of technology R&D in the last half decade or so. The core idea is a re-invention of some of concepts and technology that [IBM invented along with the hypervisor](https://www.theregister.com/2011/07/14/brief_history_of_virtualisation_part_2/) in the 1960s: designing OSes specifically to run as guests under another OS. This means building the OS specifically to run inside a VM, and to talk to resources provided by a specific hypervisor rather than to fake hardware.

This means that the guest OS needs next to no support for real hardware, just [VirtIO](https://wiki.osdev.org/Virtio) drivers which talk directly to facilities provided by the host hypervisor. In turn, the hypervisor doesn't have to provide an emulated PCI bus, emulated power management, emulated graphics card, emulated network interface cards, and so on. The result is that the hypervisor itself can be much smaller and simpler.

The result of ruthlessly chopping down both the hypervisor, and the OS that runs inside it, is that both ends can be much smaller and simpler. That means that VMs can use much fewer resources, and start up much quicker.

At the moment, the commercial goal of this is providing "serverless" compute power. "Serverless" computing is marketing double-speak, really: of course there really are servers, somewhere in a datacenter. But rather than providing Infrastructure as a Service, the famed IaaS model, this is [Function as a Service instead](https://www.theregister.com/2018/12/19/serverless_computing_study/). The idea is that you don't need to know anything about the infrastructure: your program calls another program, and the management tooling spawns as many instances as needed to run that specific operation, return the result, and then delete the VMs used to run the calculations. You never need to know where it happened or how.

For the customer, it's good because it's fast and it's easy. For the providers, it's good because it means the resources are freed up again much more quickly, so they can reused immediately, which means supporting more customers on the same amount of hardware.

AWS is offering FaaS via a service called Lambda, after an arcane bit of functional programming terminology. Lambda is powered by Amazon's home-grown [Firecracker hypervisor](https://www.theregister.com/2018/11/27/aws_sets_firecracker/) which also powers its [Fargate serverless offering](https://www.theregister.com/2020/04/09/aws_revamps_fargate_serverless_containers/).

Firecracker is based on the Linux kernel's built-in KVM hypervisor: in itself, something of a departure, as up until then, [AWS was based on the Xen hypervisor](https://www.theregister.com/2017/11/07/aws_writes_new_kvm_based_hypervisor_to_make_its_cloud_go_faster/). This means it's inherently a Linux-on-Linux offering. That sounded like a challenge to FreeBSD kernel developer Colin Percival, as we [reported on a year ago](https://www.theregister.com/2022/10/19/freebsd_comes_to_amazons_lightweight/): he decided to get FreeBSD running on Firecracker. As with most of computing in general, though, the overall optimization process is: first, get it working at all; then, make it go fast.

According to his [tweet](https://twitter.com/cperciva/status/1693127769901969772) earlier this week, his latest performance optimization is impressive: replacing a sort algorithm made part of the FreeBSD kernel startup process around a *hundred times* faster, bringing the kernel loading time down to an impressive 25 milliseconds. That's a quarter of one-tenth of a second.

FreeBSD (HEAD) no longer spends time running a bubblesort on its SYSINITs. We're now running a mergesort which is ~100x faster:

— Colin Percival (@cperciva)[https://t.co/1F8Yodedh3][https://t.co/AvmVVwz9G5][August 20, 2023]

This tweak is just the latest in a long series, which he described in much more [detail](https://www.usenix.org/publications/loginonline/freebsd-firecracker) a couple of days later. It describes the preliminary changes needed to get it booting at all: removing several initialization steps which assumed it was booting under Xen, then querying ACPI for the type and number of processors. That failed, as Firecracker doesn't provide ACPI. Then, initialization of one of the only bits of hardware it does emulate, a serial console, failed.

After the kernel was successfully starting, memory usage quickly became a problem: Firecracker defaults to assigning the guest a mere 128MB of RAM, due to an assumption which had to be changed. What follows is a whole laundry list of optimizations, each of which contributed a small time saving.

It's an interesting read, even if you're not super technical. Some of the steps change things that were quite reasonable choices for booting on dedicated hardware, which no longer make sense in a virtual environment where a machine is spawned, does some work, and is deleted again within a matter of a few seconds.

Percival [commented](https://news.ycombinator.com/item?id=37205578):

I believe Linux is at 75-80 ms for the same environment where I have FreeBSD booting in 25 ms.


And [continued](https://news.ycombinator.com/item?id=37205475):

When I started working on speeding up the boot process, the kernel took about 10 seconds to boot, so I have a kernel booting about 400x faster now than I did a few years ago.


For now, the optimized kernel is the FreeBSD 14 one, on x86-64, but work is underway to bring it to Arm64 as well — AWS is [the biggest user of Arm servers](https://www.theregister.com/2023/08/08/amazon_arm_servers/) in the world.

[Spotted in the wild: Chimera – a Linux that](https://www.theregister.com/2023/02/13/chimera_non_gnu_linux/)*isn't*GNU/Linux[helloSystem 0.8: A friendly, all-graphical FreeBSD](https://www.theregister.com/2023/01/31/hellosystem_08/)[Double BSD birthday bash beckons – or triple, if you count MidnightBSD 3.0](https://www.theregister.com/2023/04/13/freebsd_132_openbsd_73/)[FreeBSD comes to Amazon's lightweight hypervisor](https://www.theregister.com/2022/10/19/freebsd_comes_to_amazons_lightweight/)

Firecracker is one of the higher-profile microVMs around, but there are others, and its success has inspired the QEMU developers to add a [microvm](https://qemu.readthedocs.io/en/v8.1.0/system/i386/microvm.html) virtual platform as well. Canonical developer Christian Erhardt has [blogged](https://cpaelzer.github.io/blogs/009-microvm-in-ubuntu/) about how to use this in Ubuntu, and online-code-development-environment vendor Hocus recently [explained](https://hocus.dev/blog/qemu-vs-firecracker/) why it switched from Firecracker to the QEMU equivalent instead.

We can see a lot of potential uses for microVMs, not just in cloud scenarios. The ability to run a single program built for one OS on top of a totally different OS, without the overhead of running a full emulated environment all the time, could be very handy in all kinds of situations.

Containers are a very useful tool, but in containers you can only run binaries for the same host OS. Running anything else – such as Docker Linux containers on macOS – means that some emulation and a guest OS have been hidden away somewhere in the stack. The smaller that VM can be, and the fewer resources it uses, the better the overall performance, not only of the containers but of the whole machine. ®

80