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.

Comments

Only for embedded devices

[Professor_Quail]

This isn't for desktop linux, only for embedded devices.

Re:Only for embedded devices

[HidingMyName]

I'm not privy to his techniques, but he may be hardwiring the compiled kernel for the target architecture to get more speed (recall that when programming, using early binding times trade off flexibility for speed). Yodaiken's a smart guy, so I may not have guessed his tricks.

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.

Re:Only for embedded devices

[ihopMaintenance]

I disabled a lot of stuff that autolaunches, like virus scanners, firewall, etc

Good idea. Virus scanners and firewalls use WAY too much overhead. Heck I used to run them and they interfered with my screen savers and stuff. Who needs em.

Re:Only for embedded devices

[danheskett]

Windows does exactly that for its "hibernate" feature. Essentially hardware is returned to a safe state (write operation suspended, etc) and the contents of memory written sequentially to a block of disk space. On boot, a small stub is loaded, which copies the data from disk to memory. Execution resumes at that point. The last thing that Windows does before hibernating is to schedule hardware re-initilization in a short period of time - essentially ensuring that things like sound cards, video cards, USB devices, etc get a "soft" reset when out of the hibernation period.

On a decent reasonable recent PC this takes a few seconds. On my fast AMD box I hit the power button and about 2 seconds later the box is off. Hit the power button again and its back on in about 4 seconds exactly where I left off. If I lost my DHCP lease in the interim it takes another 3-4 seconds for network connections to resume.

But whats best about the changes MS made to Windows XP is the multi-threaded boot process. Other than the kernel load the userland stuff is mostly all multi-threaded even on boot. This means services and whatnot are starting concurrently without waiting for other things to finish. Its somewhat less safe - a failed service could potentially cause others to hang and lock the system and/or cause a reset - however, I've yet to see that problem in the field. The net result is that on a typical AMD/P4 Windows XP box you can get to a login prompt/welcome screen in under 30 seconds, often under 20.

Users I've switched from XP to various Linuxes have all complained about the boot times - Red Hat 8 on similiar hardware takes eons to get a graphical login prompt. SuSE is just as bad. Mandrake is somewhat better, but all are in the minutes not seconds metric.

incredible

[alienhazard]

this is certianly incredible, but it is not yet available for x86 platforms. Do note, that this is not the boot sequence up till you get the login prompt, but just the initial loading of the kernel.

kernel boot != complete system initialization

[Ankh]

Note that for embedded systems the main interest is how long it takes for the kernel to load, not how long it is before a multi-user server or workstation has a prompt that says "login" on a pretty X display.

So, this is a good improvement it seems, but shaves away 4.5 seconds or so out of maybe 30 sconds or over a minute for many people. Combined with the parallel init scripts work mentioned a few days ago,though, I'm guessing that Linux systems will be booting a lot faster with the major releases in 6 months to a year.

Booting Linux Faster through Blocking

[Eponymous Cowboy]

Although this article refers to embedded systems, the earlier Booting Linux Faster article contained an overlooked post by TornSheetMetal, who had a great idea on how to make Linux, or any operating system start up faster on any system.

Simply run every startup script simultaneously, but have each script block until its dependencies have started. Nothing waits longer than it needs to, and there is no need for additional complex systems to check and manage dependencies.

This is VERY easy to do with daemontools and svok (both written by D.J. Bernstein, the author of qmail). Switch over and you'll never go back.

Re:Booting Linux Faster through Blocking

[Anonymous Coward]

That's why it is necessary to do what Windows XP does: each time it boots, it records the order of sector accesses. Then, when it is later idle, it reorganizes those sectors to optimize them for the next boot--a much smarter form of the traditional "defragmentation." The result is a recursive iteration to the optimal sector organization, and the fastest possible boot. (Incidentally, it also does this while loading each individual application, which is why applications start so much faster under XP than 2000.)

Re:Which prompts the question:

[Anonymous Crowhead]

alias uptime="echo '5:33pm up 22342352324 days, 6:28, 2124315623 users, load average: 2432.40, 12312.31, 123123.19'"

No, it is not that simple at all.

[seanadams.com]

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).

Good news. Now my software can be more buggy.

[stienman]

I had a professor tell us this story of one of his previous coworkers:

She had designed and implemented a simple service on top of unix which was accessed by a moderate number of users. When the time to put it into production came, she looked at her remaining few crashing bugs and determined to put in a monitoring loop that would reboot the server if such a situation happened. She also determined that no data loss would occur.

Why did she do this workaround, and how did she determine what bugs she could leave in?

She had a 5 digit company phone extension. She determined that someone could call her, if she let her phone ring twice, in a short period of time. During this time the server would have finished rebooting and start serving again. She could answer the call and simply say, "Try it again", whereupon the user would find that his operation worked this time.

So remember - if your server can reboot itself (and does so automatically and safely) before they can finish dialing tech support, you have no worries!

-Adam

Re:why is it ...

[seanadams.com]

They only have to distribute their source to whomever they distribute a binary, if and when they do so. Under the GPL you do not bear the burden of publishing, distributing, and supporting source changes that you made for your own use, or changes which you have not yet distributed.

Re:NOT Only for embedded devices RTFA

[jonadab]

Nevertheless, it's clear in the article that we're only talking about
kernel boot time here (which is usually about five seconds). The
_other_ three hundred seconds your system spends booting (starting
all the services and stuff, then X, then your desktop environment,
then any apps) are unaffected.