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