The 1-Second Linux Boot 156
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."
Re:Specialized platform... (Score:3, Interesting)
An OS optimized for a single platform being loaded uncompressed from ROM (or in this case flash) is nothing special.
The popular Atom-based netbooks are so similar that they're almost "a single platform", and a lot of them have flash from which one can load an uncompressed kernel (or one lightly compressed with a cheap codec like LZO).
Heck, many of the computers of 30 years ago booted up in a second or two for the same reasons.
So why do computer users let Wirth's law [wikipedia.org] overpower Moore's?
Sense? (Score:2, Interesting)
Apart from the “because I can”, what’s the actual point of this?
I mean restarting the computer is rather a Windows thing. Why would you reboot a Linux machine? There isn’t a new kernel that often...
If it’s a desktop, you are going to switch it on in the morning, go take a piss, enter the password, go find something to eat, and then it runs for the day. Same thing when you were away and came home.
And for anything else (e.g. laptops) there always is hibernation.
Also the trick to make shutdown actually reboot and go to hibernation, helps with doing actual reboots.
Re:Sense? (Score:5, Interesting)
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.
Why not do this for desktop OSs? (Score:5, Interesting)
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.
Re:Specialized platform... (Score:5, Interesting)
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.
Re:Why not do this for desktop OSs? (Score:4, Interesting)
It's good, but ... (Score:3, Interesting)
I build little embedded(ish) systems myself - AMD Geode boxards (ALIX) and my custom compiled kernel boots in 1.08 seconds (according to kernel output) If I didn't compile in networking and USB, I'm sure it would be under a second.
The biggest time is the boards BIOS (5 seconds), then loading the image off flash then the kernel uncompressed and boots - 1.08 seconds.
If I had more access to the board and had 4MB of flash ram as part of the memory map, then I could eliminate the long BIOS + Load times and jump into kernel on cycle 0. That's where the trick is, I guess - a fast load of the kernel into RAM, or keep it in FLASH that's part of the memory map.
After the kernel is loaded it's just userspace - I run a cut-down system, but it still takes another 15-20 seconds or so to get time, dns, networking, apache, etc. going. You're probably not doing that with an in-car device or a camera, etc.
So it's not really hard to make a kernel boot fast and possibly even launch one application - the big savings are going to be on the hardware when you can eliminate BIOS and load times, and the amount of userland you then have to load - which is the real difference between "embedded" and general purpose (e.g. desktop)