FreeBSD can now boot in 25 milliseconds
- Reference: 1693314128
- News link: https://www.theregister.co.uk/2023/08/29/freebsd_boots_in_25ms/
- Source link:
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 [1]IBM invented along with the hypervisor 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 [2]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.
[3]
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.
[4]
[5]
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 [6]Function as a Service instead . 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.
[7]
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 [8]Firecracker hypervisor which also powers its [9]Fargate serverless offering .
Firecracker is based on the Linux kernel's built-in KVM hypervisor: in itself, something of a departure, as up until then, [10]AWS was based on the Xen hypervisor . This means it's inherently a Linux-on-Linux offering. That sounded like a challenge to FreeBSD kernel developer Colin Percival, as we [11]reported on a year ago : 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 [12]tweet 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: [13]https://t.co/1F8Yodedh3 [14]https://t.co/AvmVVwz9G5 — Colin Percival ( @cperciva ) [15]August 20, 2023
This tweak is just the latest in a long series, which he described in much more [16]detail 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.
[17]
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 [18]commented :
I believe Linux is at 75-80 ms for the same environment where I have FreeBSD booting in 25 ms.
And [19]continued :
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 [20]the biggest user of Arm servers in the world.
[21]Spotted in the wild: Chimera – a Linux that isn't GNU/Linux
[22]helloSystem 0.8: A friendly, all-graphical FreeBSD
[23]Double BSD birthday bash beckons – or triple, if you count MidnightBSD 3.0
[24]FreeBSD comes to Amazon's lightweight hypervisor
Firecracker is one of the higher-profile microVMs around, but there are others, and its success has inspired the QEMU developers to add a [25]microvm virtual platform as well. Canonical developer Christian Erhardt has [26]blogged about how to use this in Ubuntu, and online-code-development-environment vendor Hocus recently [27]explained 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. ®
Get our [28]Tech Resources
[1] https://www.theregister.com/2011/07/14/brief_history_of_virtualisation_part_2/
[2] https://wiki.osdev.org/Virtio
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZO4WJGaVQCMDVQoSxcc08AAAA9A&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZO4WJGaVQCMDVQoSxcc08AAAA9A&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZO4WJGaVQCMDVQoSxcc08AAAA9A&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2018/12/19/serverless_computing_study/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZO4WJGaVQCMDVQoSxcc08AAAA9A&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2018/11/27/aws_sets_firecracker/
[9] https://www.theregister.com/2020/04/09/aws_revamps_fargate_serverless_containers/
[10] https://www.theregister.com/2017/11/07/aws_writes_new_kvm_based_hypervisor_to_make_its_cloud_go_faster/
[11] https://www.theregister.com/2022/10/19/freebsd_comes_to_amazons_lightweight/
[12] https://twitter.com/cperciva/status/1693127769901969772
[13] https://t.co/1F8Yodedh3
[14] https://t.co/AvmVVwz9G5
[15] https://twitter.com/cperciva/status/1693127769901969772?ref_src=twsrc%5Etfw
[16] https://www.usenix.org/publications/loginonline/freebsd-firecracker
[17] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZO4WJGaVQCMDVQoSxcc08AAAA9A&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[18] https://news.ycombinator.com/item?id=37205578
[19] https://news.ycombinator.com/item?id=37205475
[20] https://www.theregister.com/2023/08/08/amazon_arm_servers/
[21] https://www.theregister.com/2023/02/13/chimera_non_gnu_linux/
[22] https://www.theregister.com/2023/01/31/hellosystem_08/
[23] https://www.theregister.com/2023/04/13/freebsd_132_openbsd_73/
[24] https://www.theregister.com/2022/10/19/freebsd_comes_to_amazons_lightweight/
[25] https://qemu.readthedocs.io/en/latest/system/i386/microvm.html
[26] https://cpaelzer.github.io/blogs/009-microvm-in-ubuntu/
[27] https://hocus.dev/blog/qemu-vs-firecracker/
[28] https://whitepapers.theregister.com/
Re: Pretty impressive
Bubblesort? That is never appropriate in production systems. It is thought up by novices when they design their first algorithm and it is always a failure to use in practice. Any good teacher will tell you the (w)holy sorted story in graded stability versions.
Re: Pretty impressive
Does anyone remember "syscon" for Novell in the '80s? This was the main admin GUI, responsible to modifying user accounts, print services, etc
I was a teaching assistant at a Florida uni and we had "Superset" visit (i.e. Drew Major and the rest of the core Novell coders)
We had something like 125 Novell servers in various departments scattered across campus, and I helped admin several for the computer science department, which had about 20K accounts for the comp sci students.
Major tries to pop up the user list in syscon, and it's sitting there flashing "Please Wait" for a LONG time, like 5 minutes. (Which we considered a standard response time)
He asks me how many people in the list, and I said "about 8K" at which point one of the other guys leans across and says to Drew, "I think that uses a bubble sort, we were kind of in a hurry"
My data structures prof was there, and I saw him turn white.
And yes, there was a point release the next month that vastly improved that performance, so I think that was a true assessment.
Re: Pretty impressive
If you're sorting a handful of items then it's not a bad choice... but the count of items has ballooned since it was chosen, and the algorithm still worked, and is fast enough that it didn't really matter when compared with the delays of waiting for hardware to do it's stuff...
I mean we're talking about a 2ms saving, on a process which (before other optimisations) took 10s.
Re: Pretty impressive
I first used quicksort in anger in 1990. I learned it during my CS degree in the late 80s. It was already two decades old then.
Re: Pretty impressive
I don't know a whole lot about the FreeBSD kernel, but, as I understand it, the system initialisation routines (or declarations thereof along with their parameters and execution priority) are spread through various parts of the code and rely on linker sets to gather them together at link time in one contiguous block.
The initialisation process then sorts that block in priority order before executing each initialisation routine in turn.
If you were looking for a more optimal process still, presumably it would be better to sort the data into the correct order within the executable as part of the build process: after that point it's never going to change. You could then dispense with the runtime sort altogether.
Re: Pretty impressive
What about replacing the init with systemd??
/thats a joke icon
/ducks and runs for cover
The bubble has burst
Getting over the shock of finding that anyone was still using a bubble sort, let alone in a kernel, I like the idea of a Micro VM, it's a good abstraction which should be used to reduce complexity in all OS's.
Pretty impressive
that a single sort algorithm was taking 99+% of the boot(init?) time.
Oh it didn't:
"FreeBSD’s mi_startup function, which kicks off machine-independent system initialization routines, was using a bubblesort to order the functions it called; while this was reasonable in the 90s given the small number of routines needing to be ordered at that point, there are now over 1000 such routines and the bubblesort was getting slow. Replacing it with a quicksort will save 2 ms. (Not yet committed as of 22 August 2023).
"