Slashdot Mirror
Software Tweak Makes Linux Boot In Under 200 ms
An anonymous reader writes "A version of Linux has been created that radically speeds up system boot time -- to less than 200 milliseconds (ms) from power-up to application code startup. The techniques, created by Real-time Linux vendor FSMLabs, are processor independent, and boot times of under 100 mS are expected in the future." Update: 09/30 01:04 GMT by T : Yep -- both headline and post should have read "ms" (milliseconds) rather than "mS" (milli Siemens); thanks to all the alert readers.
Keep the image that the kernel creates AFTER boot - simply load that into memory and restart.
That said - you still need the long boot the first time, and after any hardware changes. Also, I am guessing to get it into the sub second range - hard drives are right out as well - and all of the silly boot managers. But for an embedded device - who cares
I have mod points and I am not afraid to use them
For the hard drive - rather than put executables down 1-n on the hard drive - Windows (for many years) figures out the load order of sectors of the executable - and fragments them across the sectors in that order - net effect +10-50% load time boost from using the hard drive effectively
For drivers - there is this really interesting way that windows is now initializing driver loading by putting them into the kernel image itself... Kind of like taking modules in Linux - and rather than having the overhead of loading the module each time you boot - insert it into the kernel - and letting the kernel load (with a "static" module in now) - This one is a little trickier to put into a Linux environment... what does the GPL say if I have a loadable module - yet the kernel now statically links it in as an optimization... I don't even want to go there
I have mod points and I am not afraid to use them
Embedded devices may not need to do things like hardware discovery, plug and play configuration, etc. since their hardware configuration may be constant (so this stuff could be compiled into the kernel). Additionally, booting the kernel is different than doing various daemon startups and file system initializations, network configuration, etc. that one typically wants for non-desktop devices.
Go RTFA - several points: You don't just simply "load an image into memory" and have a running system. This is why properly supporting APM is difficult on any machine. All your hardware needs to be reinitialized. Network connections need to be reestablished (getting IP and so on), file systems need to be remounted, there are all kinds of timer-driven things that need special handling, and so on and so forth.
What these guys are doing is optimizing for embedded systems - where the kernel is hardwired for exactly the same hardware every time. You don't need to probe, and you don't need to guess what state the hardware is in - it's a closed system and it's the same at every power-on. Furthermore there are all kinds of things you can initialize simultaneously when you can optimimize for a deterministic environment - if your video system wants a moment to do a POST, you can spend that time initializing a network interface, for example.
Also, the definition of "boot time" for this dicussion is the time until the first application-level code runs. That's something like only 1/3 to 1/2 of the boot time for a typical linux server or desktop that you're thinking of. Most of the time is spent bringing up userland services and loading the graphical environment. There's a big savings on big workstation in flushing RAM to disk, but not so much for small embedded systems, where application state is very minimal (eg a Tivo, or a wireless router).
RiscOS could get from a cold boot to the GUI in less than 4 seconds on an ARM3/8MHz.
I can't even measure it now on a StrongARM/202MHz, also consider the newest RiscOS powered computer : Iyonix (Xscale/600MHz)...
Trolling using another account since 2005.
Yeah, tried using that mode once on Windows98: Restarting after the hibernate didn't go as smoothly as one hoped:
Oh, come on now... I'm no MS apologist, but Win98's power management support was notoriously bug infested. (I know - I was Program Manager for Dell's laptops when it was introduced!)
Comparing this to W2K or XP is like comparing DOS to VMS. There are similarities, but they are only superficial. Power managment in XP is flawless, and implemented FAR better than in even the latest mainstream Linux distros, which always seem to be two years behind the times in hardware support. (
Sadly, PM has never been very good in Linux, I think mostly because of the anti-MS bias - If you don't hang out at the Windows Hardware Developer Conference, how are you going to know enough about the PCxx standards (which, like it or not, *define* what a PC is and how it works) to write good PM code? Answer: You can't!
I have to say though, despite the fact that I really dislike some of Microsoft's business practices, I recently upgraded my primary desktop to XP, and it's *by far* the best desktop environment I've ever used (after expunging IE/OE for Mozilla). Like it or not, XP is a real OS, and particularly as a desktop (still 100% BSD/Linux for servers), it's the most stable and functional setup I've seen. (And this is with the low-budget XP Home, since I didn't really need the few extra features of Pro they charge another $100+ for.)
If I sound surprised, it's because I am - W2K was the first "real OS" from Redmond, and XP is a much bigger improvement on it than I expected. Now if they could just secure it, and would quit intentionally breaking things... (like for instance *every* (older) version of Visio - Grrrr)
"The future's good and the present is nothing to sneeze at." - Roblimo's last