6 ms·

Based on the kernel boot time (28 ms) given by the author, this process takes 1.97 milliseconds. I'd consider this less "haha dum code is slow" and more "you a

by gkbrk 3y ago

Based on the kernel boot time (28 ms) given by the author, this process takes 1.97 milliseconds. I'd consider this less "haha dum code is slow" and more "you are booting the kernel way too much, even a 1.97 millisecond delay is noticable".

cperciva 3y ago
2.031 ms, I rounded down.
lkbm 3y ago
Probably true. My question was "how often is this run?" I assume it's not just once when I first turn on my laptop from fully off. Is it once every time I restart a Docker container? (Assuming FreeBSD images.) Is it something that runs a couple times a day, a dozen times a day, a thousand times a day? Fifty times every time I open an Electron app? I suspect this doesn't matter and is more a curiosity, but I wouldn't be shocked to learn otherwise.
rwmj 3y ago
Sure but Firecracker is used for AWS lambdas, so you're going to be booting those extremely frequently. (Now I wonder if Amazon is using FreeBSD for AWS lambda ..?)
- cperciva 3y ago
  AWS Lambda does not support FreeBSD. It would be great if that changed though...
MrDOS 3y ago
I think the “Firecracker” referenced in this Tweet is Amazon's “microVM” environment[0]. VMs running in this environment are sometimes booted to service scheduled/batch jobs, but are, I think, more often launched in direct response to (and with the intent of serving) an incoming HTTP request (and then stick around for a few minutes afterwards in case there are any subsequent requests). Network latency from the continental US to the nearest AWS datacentre is typically <30ms, so even after you add the response time of the application running in the VM, an extra 2ms boot time still probably makes up >2% of the total cold response time. [0]: https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/
- trasz4 3y ago
  This will also make a lot of difference once we can run lightweight, userspace kernels ("rump kernels").
  - yjftsjthsd-h 3y ago
    > once we can run lightweight, userspace kernels ("rump kernels"). Er, didn't NetBSD accomplish that... like a decade ago, now? Or is FreeBSD looking into supporting rump kernels?
    - trasz4 3y ago
      Yes, NetBSD did accomplish that, but I expect it to become more commonplace.
      - EuropeOverlords 3y ago
        but question is, is this solution for people running software on other peoples computers ? or solution for running my own code on my own computer only ?
        yjftsjthsd-h 3y ago
        Does it matter? Running kernel pieces in userspace is useful in both directions (rather like docker), and in both cases we'd like it to run as quickly as possible.
        trasz4 3y ago
        For my particular case it's about something similar in purpose to sandboxing, but with providing the compartment (ie a process subtree) with an alternative kernel to talk to, to minimise the attack surface between that container and the host kernel.
- chongli 3y ago
  So wouldn't this fall under the category of "booting the kernel too much"? Why not find a way to keep already-booted kernels laying around and recycle them, rather than rebooting them afresh on every request? This pattern has already played out in other situations and been solved this way, such as with object pools or thread pools.
Qweiuu 3y ago
We now boot so often kernels this is important. My tv boots a kernel, Alexa's, laptops, cars etc. And this might be not specifically critical but it's a sign of people just doing something less optimal
- LeifCarrotson 3y ago
  Do you think those devices boot every time you send them an input, or just when they're plugged in? Unless you're turning the TV on and off thousands of times per day this would be unnoticeable.
  - treesknees 3y ago
    Certain systems on a vehicle make sense to power off. Do you really need the unit controlling your backup camera to be booted into standby while the car is turned off?
    - LeifCarrotson 3y ago
      No, but I'm not taking thousands of six-inch family vacations per day, I'd walk if I wanted to travel a distance for which two milliseconds was noticeable.
      - treesknees 3y ago
        I think you're mixing (bad) analogies to make some type of point but I'm not sure what it is. The original comment you replied to mentioned cars in the context of booting devices often, so I simply pointed out that yes, actually it makes sense to boot up some devices when they go to receive input and not to leave them in standby as you suggested. In a vehicle that may sit off/idle for several weeks, it's best not to drain the battery unnecessarily.
  - Qweiuu 3y ago
    I probably boot a few embedded devices per day. If someone did not optimize this this might indicate other optimizations
Paul-Craft 3y ago
Yeah, and Ahmdal's law comes directly into play here. At 7% of the total boot time, this bubble sort may be the slowest part of the kernel boot. But, even if you optimized away the sort entirely somehow, you could still only save 1.97 ms. And once you do that, the next slowest thing probably doesn't take more than ~1ms to run. Eventually, you get to a state that resists these kinds of targeted optimizations, where there are no bottlenecks, and the only improvements can come from new algorithms and data structures, i.e. "uniformly slow code." Of course, calling anything that takes place in less than a blink of an eye "slow" is overstating things... lol :-) If only I could get my desktop environment to come up in less than 28ms :-) https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law https://wiki.c2.com/?UniformlySlowCode https://wiki.c2.com/?UniformlySlowCode
- EuropeOverlords 3y ago
  exactly, it is not problem of making it slower / faster or which is slower/ faster. BUT that we use solutions across multiple problems instead providing solution specifically for that problem. if you have KNOWN vm, on KNOWN hardware then why you need all kinds of hardware and other bull.. initializations, checks.... ? just provide list of things it has to have then after list is run over without problem, continue. also why would amazon/gcp/azure care ? they are making money from you running inefficient solutions....
  - EuropeOverlords 3y ago
    main point of running unixy stuff is exactly that i can mold my solution to specific problem EASILY. thats why it is so common in embedded market ( routers, kiosks,drones, car infotainment, TV... )
pjc50 3y ago
So that's a very impressive number, but how long does it take to bring up userland?
- loeg 3y ago
  Years (to be a little hyperbolic). FreeBSD still doesn't have a good pid 1 story. It still has a very simple /sbin/init that just spawns whatever shell script happens to live in /etc/rc. That shell script essentially does a topology sort of service dependencies and then starts each one individually and serially.
shpx 3y ago
You lack the imagination to come up with a use for some improvement off the cuff, that doesn't mean everyone else (some of whom are more motivated) does as well. Why do we even need to waste any consciousness-seconds on watching electric circuits initialize? Computers should just start working

by gkbrk 3y ago

cperciva 3y ago

2.031 ms, I rounded down.

lkbm 3y ago

Probably true. My question was "how often is this run?" I assume it's not just once when I first turn on my laptop from fully off. Is it once every time I restart a Docker container? (Assuming FreeBSD images.) Is it something that runs a couple times a day, a dozen times a day, a thousand times a day? Fifty times every time I open an Electron app? I suspect this doesn't matter and is more a curiosity, but I wouldn't be shocked to learn otherwise.

rwmj 3y ago

Sure but Firecracker is used for AWS lambdas, so you're going to be booting those extremely frequently. (Now I wonder if Amazon is using FreeBSD for AWS lambda ..?)

cperciva 3y ago
AWS Lambda does not support FreeBSD. It would be great if that changed though...

MrDOS 3y ago

I think the “Firecracker” referenced in this Tweet is Amazon's “microVM” environment[0]. VMs running in this environment are sometimes booted to service scheduled/batch jobs, but are, I think, more often launched in direct response to (and with the intent of serving) an incoming HTTP request (and then stick around for a few minutes afterwards in case there are any subsequent requests). Network latency from the continental US to the nearest AWS datacentre is typically <30ms, so even after you add the response time of the application running in the VM, an extra 2ms boot time still probably makes up >2% of the total cold response time. [0]: https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/

trasz4 3y ago
This will also make a lot of difference once we can run lightweight, userspace kernels ("rump kernels").
- yjftsjthsd-h 3y ago
  > once we can run lightweight, userspace kernels ("rump kernels"). Er, didn't NetBSD accomplish that... like a decade ago, now? Or is FreeBSD looking into supporting rump kernels?
  - trasz4 3y ago
    Yes, NetBSD did accomplish that, but I expect it to become more commonplace.
    - EuropeOverlords 3y ago
      but question is, is this solution for people running software on other peoples computers ? or solution for running my own code on my own computer only ?
      - yjftsjthsd-h 3y ago
        Does it matter? Running kernel pieces in userspace is useful in both directions (rather like docker), and in both cases we'd like it to run as quickly as possible.
      - trasz4 3y ago
        For my particular case it's about something similar in purpose to sandboxing, but with providing the compartment (ie a process subtree) with an alternative kernel to talk to, to minimise the attack surface between that container and the host kernel.
chongli 3y ago
So wouldn't this fall under the category of "booting the kernel too much"? Why not find a way to keep already-booted kernels laying around and recycle them, rather than rebooting them afresh on every request? This pattern has already played out in other situations and been solved this way, such as with object pools or thread pools.

Qweiuu 3y ago

We now boot so often kernels this is important. My tv boots a kernel, Alexa's, laptops, cars etc. And this might be not specifically critical but it's a sign of people just doing something less optimal

LeifCarrotson 3y ago
Do you think those devices boot every time you send them an input, or just when they're plugged in? Unless you're turning the TV on and off thousands of times per day this would be unnoticeable.
- treesknees 3y ago
  Certain systems on a vehicle make sense to power off. Do you really need the unit controlling your backup camera to be booted into standby while the car is turned off?
  - LeifCarrotson 3y ago
    No, but I'm not taking thousands of six-inch family vacations per day, I'd walk if I wanted to travel a distance for which two milliseconds was noticeable.
    - treesknees 3y ago
      I think you're mixing (bad) analogies to make some type of point but I'm not sure what it is. The original comment you replied to mentioned cars in the context of booting devices often, so I simply pointed out that yes, actually it makes sense to boot up some devices when they go to receive input and not to leave them in standby as you suggested. In a vehicle that may sit off/idle for several weeks, it's best not to drain the battery unnecessarily.
- Qweiuu 3y ago
  I probably boot a few embedded devices per day. If someone did not optimize this this might indicate other optimizations

Paul-Craft 3y ago

Yeah, and Ahmdal's law comes directly into play here. At 7% of the total boot time, this bubble sort may be the slowest part of the kernel boot. But, even if you optimized away the sort entirely somehow, you could still only save 1.97 ms. And once you do that, the next slowest thing probably doesn't take more than ~1ms to run. Eventually, you get to a state that resists these kinds of targeted optimizations, where there are no bottlenecks, and the only improvements can come from new algorithms and data structures, i.e. "uniformly slow code." Of course, calling anything that takes place in less than a blink of an eye "slow" is overstating things... lol :-) If only I could get my desktop environment to come up in less than 28ms :-) https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law https://wiki.c2.com/?UniformlySlowCode https://wiki.c2.com/?UniformlySlowCode

EuropeOverlords 3y ago
exactly, it is not problem of making it slower / faster or which is slower/ faster. BUT that we use solutions across multiple problems instead providing solution specifically for that problem. if you have KNOWN vm, on KNOWN hardware then why you need all kinds of hardware and other bull.. initializations, checks.... ? just provide list of things it has to have then after list is run over without problem, continue. also why would amazon/gcp/azure care ? they are making money from you running inefficient solutions....
- EuropeOverlords 3y ago
  main point of running unixy stuff is exactly that i can mold my solution to specific problem EASILY. thats why it is so common in embedded market ( routers, kiosks,drones, car infotainment, TV... )

pjc50 3y ago

So that's a very impressive number, but how long does it take to bring up userland?

loeg 3y ago
Years (to be a little hyperbolic). FreeBSD still doesn't have a good pid 1 story. It still has a very simple /sbin/init that just spawns whatever shell script happens to live in /etc/rc. That shell script essentially does a topology sort of service dependencies and then starts each one individually and serially.

shpx 3y ago

You lack the imagination to come up with a use for some improvement off the cuff, that doesn't mean everyone else (some of whom are more motivated) does as well. Why do we even need to waste any consciousness-seconds on watching electric circuits initialize? Computers should just start working