[HN Gopher] A NetBSD/amd64 guest can now boot in 18ms
       ___________________________________________________________________
        
       A NetBSD/amd64 guest can now boot in 18ms
        
       Author : bleusink
       Score  : 95 points
       Date   : 2024-01-16 16:15 UTC (6 hours ago)
        
 (HTM) web link (old.reddit.com)
 (TXT) w3m dump (old.reddit.com)
        
       | pantantrant wrote:
       | What's the firecracker command for this? (and also for Linux)
        
         | datadeft wrote:
         | I am assuming your asking about how to boot up the image. You
         | can poke around here:
         | 
         | https://dev.l1x.be/posts/2020/12/13/diving-into-firecracker-...
         | 
         | If you are asking for the NetBSD image I am not sure.
        
         | doakes wrote:
         | I like this resource for starting a VM from a container image:
         | https://github.com/alexellis/firecracker-init-lab
        
       | alberth wrote:
       | How does this compare to other BSDs?
       | 
       | Wasn't there recently a lot of work to reduce the time on FreeBSD
       | (and it's 20ms)
       | 
       | https://www.usenix.org/publications/loginonline/freebsd-fire....
        
         | jedberg wrote:
         | This work is based on the FreeBSD work.
        
         | dchest wrote:
         | "I think the fastest I got the FreeBSD kernel booting in
         | Firecracker was 21 ms. NetBSD is now at 18 ms... I need to go
         | back and address some more of the issues I noticed but didn't
         | get around to fixing.
         | 
         | Anyone know what the current record for Linux is? Last I heard
         | was ~50 ms."
         | 
         | - @cperciva at
         | https://twitter.com/cperciva/status/1747270461095043532
        
           | alberth wrote:
           | > "I need to go back and address some more of the issues I
           | noticed but didn't get around to fixing."
           | 
           | I wonder if this is related to what Netflix found as a
           | regression.
           | 
           | Starting at slide #18 below
           | 
           | https://people.freebsd.org/~gallatin/talks/OpenFest2023.pdf
        
       | myself248 wrote:
       | [in mice]
        
       | csdvrx wrote:
       | That's nice, personally it takes me about 400 ms to start a linux
       | kernel with qemu (more time is spent by qemu initializing its
       | network interfaces that starting the kernel and the init!)
       | 
       | I'll see which tricks can be reused on linux, as I'd love to cut
       | that by 1 order of magnitude!
        
       | lateralux wrote:
       | Very interesting
        
       | wang_li wrote:
       | 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.
        
         | tristor wrote:
         | 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 supports
         | injection of this information from the VM host in advance of
         | initialization, and there's probably a bunch of possible
         | security issues involved as well.
        
           | anthk wrote:
           | NetBSD can just trim the kernel down to Virtio support and
           | not much more.
        
           | alexey-salmin wrote:
           | 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.
        
         | andai wrote:
         | I wonder the same thing for my regular OS too. Sure the first
         | time it boots on this hardware, it needs to see what's what.
         | But the subsequent hundred/thousand boots, at least for my
         | usage, will be identical.
        
           | vel0city wrote:
           | 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.
        
             | walteweiss wrote:
             | Is it Windows or BIOS/UEFI option? Will it work on Linux,
             | *BSDs?
        
               | yjftsjthsd-h wrote:
               | That particular feature is a Windows feature, though
               | there's no reason you theoretically couldn't do something
               | similar on another OS.
        
           | goneri wrote:
           | Before you can reload some previous known state, you need to
           | initialize the hardware, load the firmwares and probe the
           | devices (USB, SATA, PCI), discover the storage volumes and
           | the partition tables. All these steps take time.
        
         | mixmastamyk wrote:
         | Sounds like resuming from a snapshot.
        
           | marwis wrote:
           | 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.
        
           | actionfromafar wrote:
           | Also sounds like unikernels.
        
       ___________________________________________________________________
       (page generated 2024-01-16 23:01 UTC)