How Kernel Hackers Boosted the Speed of Desktop Linux 380
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."
Re:Yeah but... (Score:5, Interesting)
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.
TFA (Score:5, Interesting)
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.
Let's head some comments off (Score:5, Interesting)
This is effectively related to an earlier Slashdot story about the changes Mandriva are making to speed up boot on their distro [slashdot.org]
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 [lkml.org] 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 [fenrus.org] and a YouTube video of the 5 second boot on an EeePC 901 [youtube.com].
Good for "appliance boxes" (Score:5, Interesting)
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.
Re:TFA (Score:5, Interesting)
Yes, please. More common users would benefit from this greatly. I would love a prompt for user and password while it is booting, because most users do not leave their computer all day, especially laptop and handheld/UMPC users.
With desktop computers, I really think that the time it takes to boot into Ubuntu, THEN going into a Gnome prompt, THEN loading the services and desktop is a silly idea.
Re:Should lead to possibly great advertisements (Score:3, Interesting)
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?
Re:Should lead to possibly great advertisements (Score:5, Interesting)
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.
Re:Should lead to possibly great advertisements (Score:5, Interesting)
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?
Important details I'm not seeing (Score:5, Interesting)
Re:Should lead to possibly great advertisements (Score:5, Interesting)
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.
Re:Should lead to possibly great advertisements (Score:3, Interesting)
Re:Should lead to possibly great advertisements (Score:4, Interesting)
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.
Re:Should lead to possibly great advertisements (Score:5, Interesting)
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.
Compilers Suck (Score:4, Interesting)
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)
Re:Should lead to possibly great advertisements (Score:2, Interesting)
This is /. and a majority of people won't like my answer. If it is available to the government (according to my understanding of the IMPRESSION of the constitution) we, as civilians likely paid for the technology to create it and thus it belongs to us and thus we should be able to own it.
Now, I know that this is going to sound retarded to most people here but I have actually given a lot of thought to this and will defend it as I can but, well, it's still sketchy in my mind.
There are some secrets (placement) that need to be maintained for a secure society. I accept that.
As a citizen should I be allowed to own and build a nuclear weapon? Yes.
Should the government be allowed to come take it away from me because they're scared? No.
Should I be allowed, as a mere citizen, to train that weapon on anything other than my own government? No.
That is the baddest of the bad. It is the WORST thing I can think of. To be allowed to operate, government owned, equipment that civilians can not access is diametrically opposed to what I think the Constitution intended. Keep in mind that I'm a bit odd in that I've driven an old Ontos down the highway (to an in a parade). I am also a Marine (in-active).
As the OPPOSITE of what people seem to think, well, I'm very much in FAVOR of what the reality should be in my opinion. As a Marine my job was to kill people and blow shit up. That is it. My job was to protect against anything unpopular in a democratic society (which we don't really have by the way) as ordered to do so by my commanding officer.
As my commanding officer is the Commander in Chief (president) most people are not able (or even willing) to defend themselves vs. a group of me. I am trained to hit my target at 500 yards. I *engage* at that. I am actually able to do so fairly easily at about 1000 yards. This is with an M16, think basically a .22 round, and open sights. Give me thirty minutes to site in a .50 cal and I'll rip your arm off at a mile away.
You, probably (though I know shit about you) aren't able to deal with that. We're no longer using a musket where you're likely to MISS your target at 50 yards. We are no longer talking about a time when the civilization is armed as well as the government.
Your role, as a civilian, is to kill me in the name of your rights (something that was actually clearly explained while I was in but the times change) should my CIC tell me to harm you to suppress your different beliefs. That is your job. If you can't do it than step aside and let those who can do so, well, do it. By the content of your last post I'm inclined to think you would if you had a reason to believe you could do so effectively.
There's the problem. I can kill six Marines on the best of days. One Marine can kill six of me. I have a life expectancy of about 3 minutes during combat. That is against third world countries. The government has prohibited you from being armed by the current definition. States have failed to uphold their duty as autonomous organizations.
As a side note? I'm brainwashed in many areas and know this to be true. In the latter paragraph I would die to protect another Marine of kill to ensure his safety. Please do look at the reasoning behind the brainwashing and understand that that is a required trait for effective soldiering. I can not speak for other branches (though I've given consideration to re-enlisting) but I think that a good percentage of MARINES would lay down their weapons if we were ever forced to train them on civilians.
I know that I don't care one bit if you are American or not. (My wife wishes it were not so.) I have absolutely nothing stopping me (even with two children) from jumping in front of a bullet for you. It is my life. I give it for humanity. Marines, regardless of the media, are something different. We have two people, fuck orders, they are the person on our left and the person on our right. When shit hits the fan don't you die Marine unles