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."
Guess Linux is faster than Slashdot.
Don't worry, it will be back in a second.
For a 1 second boot, it takes a 2.5 minute video to demonstrate it.
Complete with a video:
http://www.theregister.co.uk/2009/07/14/montavista_boasts_1sec_linux_boot/
It must have been his first time.
This is a linux computer in a car that has very specific hardware and limited functionality. Wake me up when you can get a true desktop machine to boot in 1 second and then we can talk. This is like saying, "My toaster runs linux and it can boot instantly!" Big freaking deal.
does it run crysis?
Ok, so that is interesting, but only just... This isnt desktop Linux so Im not sure why you are saying "eat that".
The OS is DMAed directly into system memory. Ok, thats kind of spiffy. That means its been "pre-loaded" which is already located.
Let me put this in perspective. Back in the mid 90s I worked at AMD. On the ÉlanSC520 system on a chip (133mhz 486 class):
So, this really isnt that spectacular - cool yes, ground breaking no.
-Foredecker
Jibe!
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.
Where's the very relevant word embedded in the Slashdot title? Even TFA's author was honest enough to include it in the original title.
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.
Way to spoil the ending of the new Zelda game.
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.
Now where did I hear something like that? Oh yeah here. Funny how every thread here on /. has at least one section where this would fit.
ACs don't waste your time replying, your posts are never seen by me.