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.
This isn't for desktop linux, only for embedded devices.
any linux user wants to sacrifice their uptime to boot faster
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.
> "I allege that SCO is full of it" -Linus
It works by loading the OS to RAMDisk from Flash... Sounds like eXecute In Place.
Not the most original thing in the world, but definitely necessary to keep Linux in step with other heavy embedded operating systems like WinCE and VxWorks.
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.
Live barefoot!
free engravings/woodcuts
Linux starts its services before it brings up the password prompt. Windows loads, displays the login prompt and continues starting services in the background.
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
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.
It's hard for thee to kick against the pricks.
Did you read the article? This was only in the context of EMBEDDED devices, and there are MANY Intel x86 embedded boards. These are very different from desktop linux, with the myriad of devices your standard PC has.
-- Patience is a virtue, but impatience is an art.
alias uptime="echo '5:33pm up 22342352324 days, 6:28, 2124315623 users, load average: 2432.40, 12312.31, 123123.19'"
Windows XP doesn't finish loading everything before you actually see the screen. Not sure about your system, but my XP get me to the welcome screen in maybe 15 second... the welcome screen then sits there for about another 5 seconds, then I finally get my login... after logging in it continue to load a lot of my device drivers which freeze the system up (not completely but make it slow to the point I can't use it) for about another 30 seconds. You could probably modify init to provide you with a login prompt before it starts running all the services... this way here you'd be able to login and use the system and the services would load up in the background while you were doing this. That's basically what XP does, realistically the time it takes me to get from loading to services start up in Linux is probably under 10 seconds... the services are what seem to take the most amount of time. They take about 20 seconds all around to load -- Depending on how many I have. My Server system boots up in about 15 seconds total from loading to login prompt... all services loaded.
...
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
Linux doesn't crash. It "creatively parks".
I have something in common with Stephen Hawking...
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).
... 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.
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
Actually, the "S" unit refers to the Imperial Second, which is defined as the interval of time between now... and now.
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.
Cut that out, or I will ship you to Norilsk in a box.
For servers a big draw back is that if you have to patch the kernel (or update it) you must reboot, but if the acual reboot only takes less than a second, users might hardly notice the downtime (you could reboot and keep a 99.99% uptime).
...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;)
It's too bad the damn power companies havn't spent some time improving their boot times... it took them like a week to restore my power *grumble*