Slashdot Mirror
How Kernel Hackers Boosted the Speed of Desktop Linux
chromatic writes "Kernel hackers Arjan van de Ven and Auke Kok showed off Linux booting in five seconds at last month's Linux Plumbers Conference. Arjan and other hackers have already improved the Linux user experience by reducing power consumption and latency. O'Reilly News interviewed him about his work on improving the Linux experience with PowerTOP, LatencyTOP, and Five-Second Boot."
ROM was a wonderful thing. Simply flip the switch and the software is already loaded into memory. There was about a second or two of initialization (on a ~1MHz 8-bit processor!) and you were ready to go. It's still possible to create such fast boot times using ROM. Especially with re-flashable ROM. These sorts of boot times are seen in systems like Game Consoles.
Unfortunately, desktop OSes are so complex that using re-flashable ROM adds a great deal of complexity and cost to the design. Thus you aren't likely to see any systems keep their OS in Flash. Compounding the problem is that modern OSes are rarely designed to boot from a ROM configuration and would require substantial changes to boot properly.
Javascript + Nintendo DSi = DSiCade
And no cheating. "Done booting means CPU and disk idle," Arjan said. No fair putting up the desktop while still starting services behind the scenes. (An audience member pointed out that Microsoft does this.) The "done booting" time did not include bringing up the network, but did include starting NetworkManager.
It seems to me that the five seconds could concievably be brought down to virtually zero with cheating! My work PC slows down so much sometimes from antivirus, inventory controls, etc that it takes longer than that to add a record or open a table in an Access database. With a keyboard buffer you could stick a fake desktop and login in, and have the real desktop and login take over before the user finished typing in his password.
Free Martian Whores!
This is effectively related to an earlier Slashdot story about the changes Mandriva are making to speed up boot on their distro
In an attempt to head off the inevitable here's a link straight to the existing
Interesting but how useful, really? thread (Yes! No! I have a Mac! I use suspend! I use hibernate! Suspend is broken for me! Hibernate is broken for me! Hibernate takes too long with 500Mbytes! Why do Linux people always say change your habits? Etc.)
What I really want to know is what can be done about usb-storage and pciehp (PCI Express hotplug). I have an EeePC 900 using a kernel with Arjan's fastboot patches and with USB entirely disabled and pciehp turned off the kernel mounts the root filesystem in just over one second. With USB on and pciehp in use it's over 5 seconds....
Finally here's a link to Arjan's slides from the presentation about 5 second boot in PowerPoint format and a YouTube video of the 5 second boot on an EeePC 901.
I'd love for my MythTV box to boot faster. Since it's not silent (though the TV fans are louder, the TV isn't always on either), I leave it turned off, and the long boot time makes it less appliance-like.
Is there any good reason the kernel can't be compiled with device drivers automatically upon installation? Even if drivers change, it can ignore the compiled one in favor of a module, and/or have a "recompile kernel for currently installed devices" button.
I also doubt the SSD is that big of an issue Windows already offers the option of using Flash ram sticks in the same way, and loading boot data sequentially on the fastest portion of the disk is also a viable (and popular) way to boost speeds.
Step 1 is making it specific, Step 2 is making it generic. I can't see any technical reason these changes can't be made generic, it's more a question of difficulty than possibility. Who is going to pay the work to generalize these changes?
says who?
We talked with both the fedora and ubuntu developers at the LPC and even they agreed that a LOT more drivers should be compiled into the kernel instead of being modules (c'mon, ext3 as a module? really?).
99% of what we did to make this work in 5 seconds applies straight for generic laptops and even most people's desktop sytems.
The speedups _still_ are relevant with generic spinning media too. Maybe those are not as fast as SSD's, but the principle is still the same (IOW, for instance reading data in the order that you need it, is better than reading it in the order that it is scattered across the hard disk)
speeding up the kernel to boot in 1 second is TOTALLY applicable to generic distros (not only that, it's relatively easy and we basically already did that).
speeding up X startup to be 1.5s is TOTALLY applicable to generic distros.
Why not?
How about the first time the system boots, it profiles what drivers are installed. It then recompiles the kernel to include those drivers.
On subsequent reboots, it uses the recompiled kernel and then, once the system is up and running, check to see if something that is compiled in is no longer needed, and see if something has been added that should be compiled in.
I'm sure it's not *that* easy, but maybe an idea for the future?
Help! I'm a slashdot refugee.
Note that nowhere in the article is there any mention of the processor, its speed or the number of cores. There's also not one word about how much RAM the machine has. With enough RAM, you can load your entire system into a RAMdisk and even if you don't have SSM access time becomes (effectively) zero. Also, of course, a 2Ghz quad core machine is going to boot faster than a 1 Ghz single core. I'm not saying they're cheating or anything, but these specs are something you need in order to evaluate what they've done, and they're not telling us.
Good, inexpensive web hosting
So basically, you could never apply these speed increases to a generic distro.
Oh come now! Never say never!
You could:
- Boot with modular kernel.
- Probe devices and get a list of loaded modules.
- Recompile kernel with said modules built-in.
- Boot with that kernel from now on.
It's relatively scriptable - in fact, I think there's a "probe loaded modules and generate new .config" script already about the place. If the user is unwilling to wait for a kernel recompile during install, just stick with the modular kernel and incrementally compile during idle time.
It's trivial. I'd code it up myself, but I'm a little busy at the moment, you understand.
You are in a twisty maze of processor lines, all alike.
There is a lot of hype here.
I would say XP can also be unusable for a minute or two after login depending on what background applications and drivers start up. Certainly a clean XP install will be usable instantly.
Yeah, but you don't need a full ESMTP server for that - a wrapper for the local delivery agent that speaks classic SMTP (but ignores most of it) should be sufficient. In fact, if you're only using it to deliver to root, you've a choice of a tiny bit of text formatting, putting into a huge block of text and whapping it onto the end of root's mailbox, or doing a tiny bit of other text formatting and use the local mail delivery agent to do all of the work.
If you've only one login account (the rest are for daemons or accessed via sudo), then the login code is excessively heavy. There's effectively only one user and effectively only one password. Those need to be in a password/shadow file for compatibility with other apps, but for machines that are essentially single-user, where the data is essentially fixed-length, you don't need search algorithms, routines to scan for the correct column, etc. You store two fixed-length blocks of data and then do a string compare and a byte compare. No files to open, no multi-layer authentication modules, etc. For a straight single-user desktop, you don't need such weight for a console login. You do for servers and other remote activity, but not for the console.
XDM/GDM/KDM could be rigged to work under GGI or XGGI. They don't need the full X system. You can complete booting that whilst the user logs in.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I picture something like that, but further.
Once the distro installer has finished it would attempt to boot the system to the graphical login. If the login screen came up it would save the state of the machine to a fast loading RAM image that GRUB could directly inject to RAM.
Reading ~100MB of system should take seconds on any machine, and the code area taken up by the GRUB routine could be overwritten with a memory offset command embedded in the first few bytes of the image.
Once the image is in RAM the execution starts up again immediately waiting for your login details.
Of course, hardware would have to be hashed to make sure that the image was still compatible with the machine and that the disk hadn't been moved to a different one. Upgrading the hardware or the kernel, software updates et cetera would require the image to be resaved, but those are easily achieved.
Taking into account the size of the image, I guess that someone could code the installer to compile the kernel with the modules the system uses built in. Maybe as a function of the exit procedure. "Optimise load time - warning! This will take quite some time"
Basically I guess what I'm saying is something like a hibernate file, but one that is rarely changed and only contains the system, not the applications running in a session.
Do not meddle in the affairs of geeks for they are subtle and quick to anger
The real lesson from all this load time buisness is that our compilers still really really suck. I mean the truth is that when you boot your computer there is only a tiny bit of logic that really needs to go on because only a small amount of stuff changes between any two boots (and less between a boot and a power off).
A truly well desgined system wouldn't care about arbitrary boundaries between this program and that one, it would hunt down optimization opportunities everywhere and automatically reduce boot up to an extremely lean and quick procedure without adopting the harms of merely loading an old image.
I mean to take one example a substantial amount of time during start up is probably spent searching for and then parsing configuration files. So long as their is no cross cutting OS level JIT compiler that can deal with both system IO code and application code there isn't much we can do about this without massive investment of effort. However, in principle there is no reason that the system couldn't simply read the preparsed data from a cache and jump directly to the real substantive logic that needs to be done on boot (checking out network conditions, looking for changed hardware, dealing with changed configs)
If you liked this thought maybe you would find my blog nice too: