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.

as if

[commodoresloat]

any linux user wants to sacrifice their uptime to boot faster

Re:as if

[robberbarron]

Uh, a Palm pilot doesn't boot when you turn it on. It merely comes out of sleep. The only time it boots is when you hit the reset button on the back. Then it takes about 5-10 seconds to boot.

However, there are a lot of embedded devices that do need to boot quickly. Automotive electronics like your radio, Nav-system, etc.. do boot up when you turn on the car, at least today they do.

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.

Re:kernel boot != complete system initialization

[Weaselmancer]

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.

True, but this is still great.

The article says, "less than 200 milliseconds (mS) from power-up to application code startup." The thing that makes this great is that not every device is going to go through the entire *nix init sequence.

How about a device like a Linux embedded router, or something like that? Just a kernel running and that's all. Or how about a dashboard mp3 player that only needs to run one application?

This makes Linux much more like customized firmware, and there are plenty of places to use that.

Granted, this'll be great when it makes it to the desktop, too. =)

Weaselmancer

Re:Slightly off topic but about *nix boot times

[gordyf]

Linux starts its services before it brings up the password prompt. Windows loads, displays the login prompt and continues starting services in the background.

Seems pretty simple to me

[MerlynEmrys67]

Rather than keeping a kernel that gets loaded at boot time...

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

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

[targo]

imply run every startup script simultaneously, but have each script block until its dependencies have started.

Btw, this is pretty much what Windows XP does, that's how it achieves a much better boot time compared to earlier Windows versions.

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'"

Another Windows optimization

[MerlynEmrys67]

Windows does some very intersting things with both optimizing the location of sectors on the hard drive and loading drivers

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

Re:Wait a second, or rather, 200ms

[Penguinshit]

Linux doesn't crash. It "creatively parks".

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

why is it ...

[sl0ppy]

... that when a company doesn't put its kernel changes out immediately, there's calls for hanging them for violating the GPL, but when a linux company optimizes boot-up routines in the kernel, nobody is asking when the patches are going to be making it into the mainline kernel?

from the looks of the article, FSMLabs has been basically profiling the kernel, looking for sticking points, and optimizing them.

why wouldn't at least some of this work be contributed back to the mainline kernel? it is modifications on a GPL'd kernel, after all.

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.

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:200 mS?

[Russ Steffen]

Actually, the "S" unit refers to the Imperial Second, which is defined as the interval of time between now... and now.

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.

And everyone knows...

[Kashif Shaikh]

...Windows might boot faster, but as we all know windows has D.S.S. capabilities which means "Delayed Service Startup":)

In other words, it loads everything AFTER you login, no joke;)