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.
yeah, I saw that too.. Slightly off topic, but what's the fastest boot time you can get with a 300mhz laptop? I have a compaq armada currently running Win 98, and if Linux can boot up faster than win 98 (I disabled a lot of stuff that autolaunches, like virus scanners, firewall, etc) I can use the laptop to take notes in lecture.
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
But what does electrical conductance have to do with boot times? 100 mS is 100 milliSiemens. Milliseconds is abbreviated ms.
)9TSS
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.
check out www.linuxbios.org. Too bad I don't have any motherboards with a supported BIOS. It sounds way cool. Kind of like turning a legacy PC into a modern embedded device. heh
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).
Try instead setting an "automatic login" to a default user... count your time period up to the point where everything has stopped loading (your hard-drive will stop ticking, heh) and all your tray icons etc etc are in place. Significant difference between that and booting just to the initial user-selection/login screen
For linux, you can try a few hard-disk tricks. Also, your filesystem might be slow... try reiser as it seems to run quite nicely. For swap partitions, put them at the end of your hard disk. Just before the swap partitions, if you have any always-loading speed-required files, try making a partition there where you can stick 'em.
There are lots of things you could tweak... being able to stick "/lib/modules" or "/usr/bin" at the end of a hard-disk could actually save you some time if you're loading a lot of stuff from there on bootup, as files on the outer rim of the HDD would load faster...
Yes, GNU/Linux could theoretically do this. But we're mostly missing/off the point of the article:
The article is talking about Linux boot times. As they mention, Linux boots in 5 seconds on most cases (embedded or on your system) from the boot loader to kernel initialization is quite fast.
The kernel (Linux) then starts loading application code (network services, security daemons, x windows, etc).
To your question: Parallelizing services initialization can dramatically improve time to log on screen (LOS). Apple did this around OS X 10.2 IIRC (went from sequential to concurrent service loading) and cut down the time to LOS dramatically.
You can probably (for example) load your network stack and local modular drivers at the same time. Then you can start all the services that depend on those: NTP, name server and mount any remote file systems. After that, most dependencies should be handled and the rest (smtp, http, ftp, telnet , ssh, etc) could all be started in the background while the system started in to multi-user mode and perhaps loaded X.
In an ideal world all those startups would be completed before any LOS is presented, but the LOS should probaly be delayed until the system has completed the load-in process.
Article X: The powers not delegated... by the Constitution...are reserved...to the people
nah, i know why they haven't released it (or at least i have a pretty good idea). my proof-of-concept code is usually tersely written and not tested under all conditions, and i'm assuming theirs is as well. i'm sure they'll release it when it's all cleaned up :)
my first part wasn't "why haven't they released this", but more a jibe at people that seem to think that releasing code is super-fast.
i've tried to go thru legal to get supposedly "proprietary" code released to GPL (even if it's a requirement of the license that legal already accepted). my thought is that we should be more patient, rather than attacking linksys, or apply that rage evenly, and complain in this case as well.
Or how about this, mod the kernel to detect a successful boot and then immediately take a snapshot of the kernel memory.
Next time on boot, just copy the memory image into ram, set the registers up right and then jump to the instruction pointer after where the snapshot was taken and just continue.
I think windows does something like that.
And I know for a fact that emacs does this to help speed up its startup time.
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.
It's been 17 seconds since you hit 'reply'! It's been 16 seconds since you hit 'reply'! It's been 15 seconds since you hit 'reply'! It's been 14 seconds since you hit 'reply'! It's been 13 seconds since you hit 'reply'!
Seeks storms aren't inevitable doing stuff in parrallel. The Kernel's quite capable of handling a modest amount of simultaneous disk accessing. It's only doing too much at once in parralel that leads to "thrashing".
Perhaps a solution would be the equivalent to "make -j", where you can tune how many simultaneous things to run. In fact "make" is a good model for this whole approach, since the control mechanism will also need to do dependency-blocking.
Other refinements that occur to me:
- Things could be marked as "light", "medium", or "heavy", and the "weight" of simultaneous running processes kept constant.
- The control process could be adaptive, tracking the "load average" and altering the "weight" of individual processes to seek a best aggregate run time.
``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.''
...) are provided as modules that are only loaded when needed. The init scripts mostly just remount the root filesystem read-write, and spawn a few ttys and allow users to log in on them. Pity I can't get decent colors on the gaphic card, otherwise it would make a great terminal.
IMHO, this is due to the Linux boot process having been inherited from Unices run on servers. Waiting a couple of minutes for the system to boot is annoying, but boot time is not really an issue on a system that is normally always up.
I have an old 486 that boots Linux in seconds (not counting the power on self test). The trick? Don't load anything you don't need. The kernel is a aggressively stripped modular kernel (with support for IDE harddisks and ext2fs built-in). Other things (drivers for the network card, floppy drive, iso9660fs,
Please correct me if I got my facts wrong.
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
I have a Dell C640 running WindowsXP Professional that does.
Specifically, I encountered each of these problems before I gave up on hibernating my laptop and resuming later.
Of course, I use a lot of command prompts. Maybe that's it? (No, I'm not running old DOS apps. I'm using command-line utilities compiled with MinGW and Cygwin.)
--JoeProgram Intellivision!