Slashdot Mirror
The 1-Second Linux Boot
An anonymous reader writes "Less than one second Linux boot! This video shows an OMAP3530 capturing video data from a camera and rendering it to an LCD display — the video appears on the LCD display in less than a second from reset."
Embedded systems, I suspect.
For servers and a fair few desktops, uptime is a virtue. They are rarely or never voluntarily shut down. For that reason, boot time isn't a huge issue(particuarly for servers, you are probably going to spend more time twiddling your thumbs while some RAID card spins up the drives and meditates upon infinity than you are actually booting your OS).
For laptops, suspend(ie. with RAM still live) is almost always the right thing to do(if the ACPI gods are with you and everything is likely to come out of suspend cleanly) because laptops almost always have at least a bit of power available. Only when the system is unplugged and the battery virtually dead do you need to bother hibernating to disk or shutting down. Again, boot time not a huge deal, though likely to be faster than either of the first two cases, because the hardware is more predictable and there are fewer disks to worry about.
Embedded stuff, though, particularly embedded stuff in certain consumer electronics, or in hostile, low-power environments, really needs to be able to wake up fast. When joe user turns on his digicam, he wants it to come up now, and he doesn't want it flattening its batteries keeping an image alive in RAM. When some minimalist sensor node with only a solar cell and a trickle-charged capacitor for company needs to wake up and transmit some data back to the mothership, it needs to spend as little energy as possible on booting, and as much as possible on sensing and transmitting.
Since Montavista is mostly known for embedded stuff, I assume that this is why they care.
What I've never quite understood is why most operating systems boot every time like it's the first time. If you look at most operating systems, they run a bunch of scripts, initialize a bunch of things, thrash the hard drive with random read and/or write patterns, and end up.. at exactly the same state every time. Why not just capture that state, and restore it?
If you think about it, the only differences between typical boots are:
- The date & time
- The type of boot (hibernation or cold boot)
- Some USB type devices that may have been plugged in or unplugged
- Minor logging events ('successful boot', 'need an fsck/chkdsk', etc...)
Really, all of that work can be done in milliseconds, not minutes. Operating systems should just read the ~100MB "ready for use" image from a nice contiguous section of the disk, write it straight into memory, and then do a quick sanity check for changed hardware.
A typical desktop SATA drive can read at 50MB/sec sequentially, so this should take, what, 2 seconds at most? On a good SSD, it should be 500ms!
I have a high-end laptop with a good SSD, and it still takes 46 seconds to go form "pressed the power button" to "logged on and usable" with Windows 7, and I suspect it wouldn't be much better with Linux.
The CPU utilization of typical machine booting in a VM with a very fast disk or SSD behind it is interesting to watch. It takes several seconds of 100% CPU time to boot either Windows or Linux. If you think about it, there's no useful computation that the OS can possibly be doing before it's booted. That's 100% wasted time.
Yup, 1-second embedded boot is fairly is fairly nice but the summary is misleading and this is not even remotely comparable to desktop boot times. They're using an initramfs, no real filesystem, and no real distribution.
To put things into perspective, I have an OMAP3530 platform in front of me (same as TFA, funny coincidence) and a totally vanilla kernel that I compiled a few days ago boots in 2.5 seconds, not counting the long time wasted by the totally suboptimal bootloader (3-second deliberate boot delay, networking support, loading the kernel from an SD card, all that crap). That time includes mounting an ext3 filesystem from an SD card and starting to run init from it, and the kernel has built-in drivers for all onboard hardware including USB host+OTG, Ethernet, networking (ipv4 and ipv6), HDMI display output, audio, etc. Of course, booting the rest of the (real, full-blown) distro up takes a while as usual, but TFA is basically showing an embedded application that could be as simple as a single binary running from initramfs (I've actually poked a MontaVista Linux system once, and their startup was basically a single shell script - not quite SysV Init!). Remove the sd/ext3 stuff, remove useless drivers, replace the bootloader with a minimal build, use a busybox shell script + a single executable binary for the actual application, and you're probably getting close to 2-second total boot times without even beginning to optimize stuff with DMA and the like.