Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A NetBSD/amd64 guest can now boot in 18ms

old.reddit.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: A NetBSD/amd64 guest can now boot in 18ms

#21

Post by marwis »

mixmastamyk wrote: post #16
wang_li wrote: post #10

I'm curious as to why this isn't 0ms for a VM. The entire state of the system can be known ahead of time. Why does the kernel need to do any kind of dynamic initialization? Why aren't all data structures and variables statically assigned to proper values for the given VM. So at VM start up time it simply enters the main dispatch loop.

Sounds like resuming from a snapshot.

Exactly, you just need to separate things that need to happen before snapshot from things that must be run every time. Then you just snapshot as part of the build.

This is how GraalVM and OpenJ9 achieve instant startup of Java programs.

Re: A NetBSD/amd64 guest can now boot in 18ms

#22

Post by alexey-salmin »

tristor wrote: post #11
wang_li wrote: post #10

I'm curious as to why this isn't 0ms for a VM. The entire state of the system can be known ahead of time. Why does the kernel need to do any kind of dynamic initialization? Why aren't all data structures and variables statically assigned to proper values for the given VM. So at VM start up time it simply enters the main dispatch loop.

Mostly because that's not how the kernel is designed. While what you're saying is true, it would require a fundamentally different kernel design. The kernel as it is today is designed to work on a variety of devices, not just VMs, so it behaves in a way in which it doesn't have specific knowledge of the device prior to initialization. To do what you're suggesting, the kernel would need to have a special mode where it…

You don't need kernel support, just freeze it's state right after the boot and clone it afterwards.

Boot time will be the setup of shadow page tables and other hypervisor structures at new offsets. Plus a few tricks to avoid reproducible RNGs.

Re: A NetBSD/amd64 guest can now boot in 18ms

#23

Post by yjftsjthsd-h »

walteweiss wrote: post #19
vel0city wrote: post #14

Earlier quoted context omitted.

That's kind of the point of Windows' Fast Boot option. The base OS pretty much just hibernates at a normal shutdown. No point in re-initializing and restarting all the base services.

Is it Windows or BIOS/UEFI option? Will it work on Linux, *BSDs?

That particular feature is a Windows feature, though there's no reason you theoretically couldn't do something similar on another OS.

Re: A NetBSD/amd64 guest can now boot in 18ms

#24

Post by actionfromafar »

mixmastamyk wrote: post #16
wang_li wrote: post #10

I'm curious as to why this isn't 0ms for a VM. The entire state of the system can be known ahead of time. Why does the kernel need to do any kind of dynamic initialization? Why aren't all data structures and variables statically assigned to proper values for the given VM. So at VM start up time it simply enters the main dispatch loop.

Sounds like resuming from a snapshot.

Also sounds like unikernels.

Re: A NetBSD/amd64 guest can now boot in 18ms

#25

Post by shaky-carrousel »

wang_li wrote: post #10

I'm curious as to why this isn't 0ms for a VM. The entire state of the system can be known ahead of time. Why does the kernel need to do any kind of dynamic initialization? Why aren't all data structures and variables statically assigned to proper values for the given VM. So at VM start up time it simply enters the main dispatch loop.

Wouldn't that mess with RNGs?

Re: A NetBSD/amd64 guest can now boot in 18ms

#26

Post by inkyoto »

alexey-salmin wrote: post #22
tristor wrote: post #11

Earlier quoted context omitted.

Mostly because that's not how the kernel is designed. While what you're saying is true, it would require a fundamentally different kernel design. The kernel as it is today is designed to work on a variety of devices, not just VMs, so it behaves in a way in which it doesn't have specific knowledge of the device prior to initialization. To do what you're suggesting, the kernel would need to have a special mode where it…

You don't need kernel support, just freeze it's state right after the boot and clone it afterwards. Boot time will be the setup of shadow page tables and other hypervisor structures at new offsets. Plus a few tricks to avoid reproducible RNGs.

> […] freeze it's state right after the boot and clone it afterwards.

You can't do that easily as devices can be attached, detached or reattached dynamically whilst the VM is running and when it is shut down.

In lieu of the hardware / VM support for device trees, with the existing design, the kernel has to probe each device upon every boot.

Re: A NetBSD/amd64 guest can now boot in 18ms

#27

Post by alexey-salmin »

inkyoto wrote: post #26
alexey-salmin wrote: post #22

Earlier quoted context omitted.

You don't need kernel support, just freeze it's state right after the boot and clone it afterwards. Boot time will be the setup of shadow page tables and other hypervisor structures at new offsets. Plus a few tricks to avoid reproducible RNGs.

> […] freeze it's state right after the boot and clone it afterwards. You can't do that easily as devices can be attached, detached or reattached dynamically whilst the VM is running and when it is shut down. In lieu of the hardware / VM support for device trees, with the existing design, the kernel has to probe each device upon every boot.

Well it's not an ordinary boot of course, it's a clone and the state on both side of the fence should be faithfully cloned including virtual devices. The guest kernel will have no way of knowing whether it was resumed once or twice.

Applicability is limited, but works well to spin up serverless compute on-demand.

Re: A NetBSD/amd64 guest can now boot in 18ms

#28

Post by pjmlp »

marwis wrote: post #21
mixmastamyk wrote: post #16

Earlier quoted context omitted.

Sounds like resuming from a snapshot.

Exactly, you just need to separate things that need to happen before snapshot from things that must be run every time. Then you just snapshot as part of the build. This is how GraalVM and OpenJ9 achieve instant startup of Java programs.

Or Smalltalk and Common Lisp images.

Re: A NetBSD/amd64 guest can now boot in 18ms

#29

Post by vel0city »

walteweiss wrote: post #19
vel0city wrote: post #14

Earlier quoted context omitted.

That's kind of the point of Windows' Fast Boot option. The base OS pretty much just hibernates at a normal shutdown. No point in re-initializing and restarting all the base services.

Is it Windows or BIOS/UEFI option? Will it work on Linux, *BSDs?

There is also often a UEFI option for a "fast boot" as well, where it skips some steps in its initialization, doesn't wait for any user input or logging to the local console if its coming back from a successful boot/power off cycle. But that's separate from the Windows feature which is related to hibernation. You could have Windows Fast Boot enabled while having your UEFI set to a full boot cycle or vice versa.

The UEFI option should work fine with pretty much any OS the hardware should be able to boot.

Post reply on HN