Weekly Edition
Return to the Front page
| |||||||||||||
LPC: Booting Linux in five secondsAt the Linux Plumbers Conference Thursday, Arjan van de Ven, Linux developer at Intel and author of PowerTOP, and Auke Kok, another Linux developer at Intel's Open Source Technology Center, demonstrated a Linux system booting in five seconds. The hardware was an Asus EEE PC, which has solid-state storage, and the two developers beat the five second mark with two software loads: one modified Fedora and one modified Moblin. They had to hold up the EEE PC for the audience, since the time required to finish booting was less than the time needed for the projector to sync. How did they do it? Arjan said it starts with the right attitude. "It's not about booting faster, it's about booting in 5 seconds." Instead of saving a second here and there, set a time budget for the whole system, and make each step of the boot finish in its allotted time. 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. A system with a conventional hard disk will have to take longer to start up: Arjan said he has run the same load on a ThinkPad and achieved a 10-second boot time. Out of the box, Fedora takes 45 seconds from power on to GDM login screen. A tool called Bootchart, by Ziga Mahkovec, offers some details. In a Bootchart graph of the Fedora boot (fig. 1), the system does some apparently time-wasting things. It spends a full second starting the loopback device—checking to see if all the network interfaces on the system are loopback. Then there's two seconds to start "sendmail." "Everybody pays because someone else wants to run a mail server," Arjan said, and suggested that for the common laptop use case—an SMTP server used only for outgoing mail—the user can simply run ssmtp.
Another time-consuming process on Fedora was "setroubleshootd," a useful tool for finding problems with Security Enhanced Linux (SELinux) configuration. It took five seconds. Fedora was not to blame for everything. Some upstream projects had puzzling delays as well. The X Window System runs the C preprocessor and compiler on startup, in order to build its keyboard mappings. Ubuntu's boot time is about the same: two seconds shorter (fig. 2). It spends 12 seconds running modprobe running a shell running modprobe, which ends up loading a single module. The tool for adding license-restricted drivers takes 2.5 seconds—on a system with no restricted drivers needed. "Everybody else pays for the binary driver," Arjan said. And Ubuntu's GDM takes another 2.5 seconds of pure CPU time, to display the background image.
Both distributions use splash screens. Arjan and Auke agreed, "We hate splash screens. By the time you see it, we want to be done." The development time that distributions spend on splash screens is much more than the Intel team spent on booting fast enough not to need one. How they did it: the kernelStep one was to make the budget. The kernel gets one second to start, including all modules. "Early boot" including init scripts and background tasks, gets another second. X gets another second, and the desktop environment gets two. The kernel has to be built without initrd, which takes half a second with nothing in it. So all modules required for boot must be built into the kernel. "With a handful of modules you cover 95% of laptops out there," Arjan said. He suggested building an initrd-based image to cover the remaining 5%. Some kernel work made it possible to do asynchronous initialization of some subsystems. For example, the modified kernel starts the Advanced Host Controller Interface (AHCI) initialization, to handle storage, at the same time as the Universal Host Controller Interface (UHCI), in order to handle USB (fig.3). "We can boot the kernel probably in half a second but we got it down to a second and we stopped," Arjan said. The kernel should be down to half a second by 2.6.28, thanks to a brand-new fix in the AHCI support, he added.
One more kernel change was a small patch to support readahead. The kernel now keeps track of which blocks it has to read at boot, then makes that information available to userspace when booting is complete. That enables readahead, which is part of the early boot process. How they did it: readahead and initFedora uses Upstart as a replacement for the historic "init" that traditionally is the first userspace program to run. But the Intel team went back to the original init. The order of tasks that init handles is modified to do three things at the same time: first, an "sReadahead" process, to read blocks from disk so that they're cached in memory, second, the critical path: filesystem check, then the D-Bus inter-process communication system, then X, then the desktop. And the third set of programs to start is the Hardware Abstraction Layer (HAL), then the udev manager for hot-plugged devices, then networking. udev is used only to support devices that might be added later—the system has a persistent, old-school /dev directory so that boot doesn't depend on udev. The arrangement of tasks helps get efficient use out of the CPU. For example, X delays for about half a second probing for video modes, and that's when HAL does its CPU-intensive startup (fig. 4).
In a graph of disk and CPU use, both are at maximum for most of the boot time, thanks to sReadahead. When X starts, it never has to wait to read from disk, since everything it needs is already in cache. sReadahead is based on Fedora Readahead, but is modified to take advantage of the kernel's new list of blocks read. sReadahead is to be released next week on moblin.org, and the kernel patch is intended for mainline as soon as Arjan can go over it with ext3 filesystem maintainer Ted Ts'o. (Ted, in the audience, offered some suggestions for reordering blocks on disk to speed boot even further.) There's a hard limit of 75MB of reads in order to boot, set by the maximum transfer speed of the Flash storage: 3 seconds of I/O at 25MB/s. So, "We don't read the whole file. We read only the pieces of the file we actually use," Arjan said. sReadahead uses the "idle" I/O scheduler, so that if anything else needs the disk it gets it. With readahead turned off, the system boots in seven seconds, but with readahead, it meets the target of five. X is still problematic. "We had to do a lot of damage to X," Arjan said. Some of the work involved eliminating the C compiler run by re-using keyboard mappings, but other work was more temporary. The current line of X development, though, puts more of the hardware detection and configuration into the kernel, which should cut the total startup time. Since part of the kernel's time budget is already spent waiting for hardware to initialize, and it can initialize more than one thing at a time, it's a more efficient use of time to have the kernel initialize the video hardware at the same time it does USB and ATA. X developer Keith Packard, in the audience and also an Intel employee, offered help. Setting the video mode in the kernel would not let the kernel initialize it at the same time as the rest of the hardware, as shown in figure 3. The fast-booting system does not use GDM but boots straight to a user session, running the XFCE desktop environment. Instead of GDM, Arjan said later, a distribution could boot to the desktop session of the last user, but start the screensaver right away. If a different user wanted to log in, he or she could use the screensaver's "switch user" button.
In conclusion, Arjan said, "Don't settle for 'make boot faster.' It's the wrong question. The question is 'make boot fast'." And don't make all users wait because a few people run a filesystem that requires a module or sendmail on their laptops. "Make it so you only pay the price if you use the feature." Distributions shouldn't have to maintain separate initrd-based and initrd-free kernel packages, he said later. The kernel could try to boot initrd-free, then fall back if for whatever reason it couldn't see /sbin/init, as might happen if it's missing the module needed to mount the root filesystem. PowerTOP spawned a flurry of power-saving hacks from all areas of the Linux software scene. The combination of Bootchart, readahead, and a five-second target looks likely to set off a friendly boot time contest among Linux people as well. At the conference roundup Friday, speaker Kyle McMartin announced that both Fedora and Ubuntu have fixed some delays in their boot process, and there was much applause. FIGURE CREDIT: Arjan van de Ven and Auke Kok, Intel(Log in to post comments)
LPC: Booting Linux in five seconds Posted Sep 22, 2008 16:25 UTC (Mon) by hummassa (subscriber, #307) [Link]
Is there a "how-to" or "make your eeepc boot in 5 seconds too" guide/tutorial
around? with the patches?
LPC: Booting Linux in five seconds Posted Sep 22, 2008 17:12 UTC (Mon) by a9db0 (subscriber, #2181) [Link]
Please? For the rest of us less-than-elite hacker types?
LPC: Booting Linux in five seconds Posted Feb 2, 2009 7:09 UTC (Mon) by lkundrak (subscriber, #43452) [Link]
Check out the alpha version of Moblin distribution, it incorporates the features mentioned in this article.
LPC: Booting Linux in five seconds Posted Sep 22, 2008 17:00 UTC (Mon) by paravoid (subscriber, #32869) [Link]
Thanks a lot for the coverage!
From the moment I saw the talk description I was wondering how on earth did they manage to cut the boot time to an order of magnitude from most systems.
They took some shortcuts but they still did some amazing work. And of course it's nice to see that it has become a target for some very capable people.
LPC: Booting Linux in five seconds Posted Sep 22, 2008 17:06 UTC (Mon) by AJWM (guest, #15888) [Link]
Cool stuff.
Just don't forget the tune2fs options so you don't get the dreaded "fsck forced" on a 200G partition...
Cheating: Not just for Microsoft anymore Posted Sep 22, 2008 17:26 UTC (Mon) by rfunk (subscriber, #4054) [Link]
"No fair putting up the desktop while still starting services behind the
scenes."
I'm pretty sure Ubuntu currently does this.
Cheating: Not just for Microsoft anymore Posted Sep 22, 2008 18:47 UTC (Mon) by SimonKagstrom (subscriber, #49801) [Link]
I've never quite understood this sentiment. As long as I can start working while the system continues to start services in the background (albeit a bit slower), I think that's great.
// Simon
Cheating: Not just for Microsoft anymore Posted Sep 22, 2008 18:58 UTC (Mon) by drag (subscriber, #31333) [Link]
It's kinda dirty.
What ends up happening is that the user is presented with something that looks like it's ready to be used, but isn't. You may be missing your networking or not have file sharing, plus your system is using up all it's I/O and cpu, which means that it's not going to be responsive or open up your applications quickly.
A extreme example of this sort of approach would be just posting a screenshot of the desktop as the splashscreen and let the parts fill in and replace bits of the screen as they are loaded. It could be a neat effect, but it would be a lousy way to hide the fact that it takes many minutes to boot up your system.
Plus the point is to have the system fully bootable. So it's a challenge, a sport, so you have to have rules so nobody tries to cheat. :) Now if you have a system that boots under five seconds, but shaves off a second or two by bringing up a fake-ish user interface then that may be something else.
Cheating: Not just for Microsoft anymore Posted Sep 22, 2008 19:38 UTC (Mon) by SimonKagstrom (subscriber, #49801) [Link]
Well, if it's a sport - I agree, there should be the same rules for everyone :-)
However, otherwise I simply want to start working as soon as possible after I've logged in (as probably most people here, I seldomly boot). Obviously showing a screenshot of the desktop is just plain silly, but why should I have to wait for some network share to be mounted unless I really need it?
Applications will start slower, sure, but if the system is unusable because of I/O caused by daemons starting in the background I'd consider that a plain bug which should be fixed.
// Simon
Cheating: Not just for Microsoft anymore Posted Sep 22, 2008 22:28 UTC (Mon) by drag (subscriber, #31333) [Link]
What if your application depends on data on a network share?
I figure the services your starting up are starting up for good reason and you'll probably have applications that depend on them. Otherwise, on a desktop, what is the point of starting them? :)
Cheating: Not just for Microsoft anymore Posted Sep 23, 2008 7:35 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
The distribution sets them up so that the user doesn't have to know about them at all. E.g. the user doesn't have to know about CUPS in order to print. (Although I would be interested to know how many Linux users have succeeded in printing without knowing about CUPS.) Of course, that could also be made more intelligent - some services could be started when they are needed by default (I thought that was the point of upstart) and automatically moved to or from autostart on boot depending on how often the user needs them.
Cheating: Not just for Microsoft anymore Posted Sep 23, 2008 15:14 UTC (Tue) by macc (subscriber, #510) [Link]
CUPS is unpleasantly opaque.
It's either there or not after
The next bloodpressure raisers
Cheating: Not just for Microsoft anymore Posted Sep 23, 2008 20:05 UTC (Tue) by nix (subscriber, #2304) [Link]
What's wrong with 'lprm'? It works for me.
Cheating: Not just for Microsoft anymore Posted Sep 23, 2008 9:08 UTC (Tue) by NAR (subscriber, #1313) [Link]
There are some daemons like spamd of spamassassin that are not necessary right after boot, so they could be started later in the background...
Cheating: Not just for Microsoft anymore Posted Sep 23, 2008 17:58 UTC (Tue) by arjan (subscriber, #36785) [Link]
Spam Assassin should just be started on first use; if you only use gmail for your email you shouldn't pay for it (both in time and memory) after all.
Cheating: Not just for Microsoft anymore Posted Sep 23, 2008 2:30 UTC (Tue) by k8to (subscriber, #15413) [Link]
Well in the windows camp, for example, you can't even successfully operate the start menu. So just triggering the attempted launch the programs you want can be really unworkable, and with a less than perfect io subsystem, your attempts to launch programs may cause thrashing, delaying your eventual ability to make use of your programs.
Linux is of course a good deal better than this, but avoiding these devils bargains is still laudible.
Cheating: Not just for Microsoft anymore Posted Oct 4, 2008 18:36 UTC (Sat) by pboddie (guest, #50784) [Link] Well in the windows camp, for example, you can't even successfully operate the start menu. Indeed. What's the point of showing the user the desktop if they can't actually use it? That's the question the Windows developers should be asking themselves.
Cheating: Not just for Microsoft anymore Posted Sep 22, 2008 19:11 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link]
On Windows boxes, at least, it's pretty onerous. On my work laptop (where I'm forced to use WinXP), it takes me about 30-40 seconds to get to the login prompt, and then another minute or so for all the background services to finish launching after logging in. The laptop isn't usable the bulk of those background services finish launching. I suspect that that's a huge source of this sentiment, at least among folks that have to use both OSes. We don't want this in our Linux. :-)
A lot of the problem is due to how Windows handles things. I can *try* to use the laptop, but random things keep killing the keyboard focus, and launching certain apps "too early" causes them to merely crash. (I suspect the app crashes are due to the firewall service, which I think is in the list of things started *after* login.) There's all sorts of stupid things in that delayed startup, such as the backup software throwing a splash screen up. I can only speculate on what keeps eating the keyboard focus. SMS scripts I suspect. (I get similar issues when the company rolls out patches--bizarre things happen to my keyboard focus and the whole desktop flashes.)
I haven't had similar issues with delayed services starting under Linux, since they are far, far less disruptive. Sure, the disk chugs a little in the background, but the only thing I've noticed is that Firefox might take a couple extra seconds to load. So, as a practical matter, some things *can* be started late without upsetting the user.
But, I suspect that wasn't the point. What ought and ought not to be started late is a judgment call, and the overall impact on the user can be difficult to judge without putting the result in front of a lot of users. For an apples-to-apples, this-is-the-real-thing-no-questions-asked comparison, it seems entirely appropriate to measure power-on to disk-and-CPU-idle. This eliminates judgment calls and fuzzy, difficult to measure impacts. It gives you a framework for tightly targeting a boot-time budget such as what Arjan described. You don't get to wiggle around the budget by saying "Oh, we can defer that one." Instead, you're forced to consider why it's slow and fix it.
If you need to throw a few things out of that initial boot, such as full network bringup in this example, then you can separately determine what its impact is.
Cheating: Not just for Microsoft anymore Posted Sep 22, 2008 19:41 UTC (Mon) by elanthis (guest, #6227) [Link]
They simply meant it wasn't fair for the sake of this exercise.
It's not wrong, if done right. It just didn't count for their target of
Cheating: Not just for Microsoft anymore Posted Sep 22, 2008 20:03 UTC (Mon) by arjan (subscriber, #36785) [Link]
We don't want to need this. We want to be DONE in 5 seconds. (and showed that it could be done)
Doing the "stuff in the background" is just hiding latency/boot time, it's not reducing it fundamentally.
Cheating: Not just for Microsoft anymore Posted Sep 23, 2008 17:36 UTC (Tue) by pjm (subscriber, #2080) [Link]
What question are we discussing here? Are we discussing what some useful rules for an artificial game are, or what should normal system startup behaviour be?
Let's address the second of those first.
Note that what's been demonstrated isn't in fact "done" by 5 seconds: networking isn't up, bluetooth isn't up, various other services aren't up. Some users do want these services to be started at around boot time (e.g. maybe they can't get any work done until the network is up, or have only a bluetooth keyboard), but may nevertheless want to be able to start work before waiting for the some services to have started. In other words, they do want the system to be "putting up a desktop while still starting services behind the scenes" (or at least put up a desktop before all services have started, i.e. further delaying some services to reduce resource contention while the user starts some applications). Certainly many users would want to be able to enter their username & password while other things are still starting, as an instance of parallelization.
That still leaves various issues like avoiding bad behaviour when applications (including the one handling the login) don't have services they need, but we can at least say that in principle users would like to have a usable desktop as soon as possible even if some services that they want to be started around boot time haven't yet started.
On to the question of good rules for a game.
The idea of having such a game is for it to result in improvements to the systems that people actually run, where "improvements" is defined by what people actually care about.
If the game rules result in a system too distant from what will run on real systems, then it's harder to translate the game-produced system across to real systems, which may result in this transferral not happening. This suggests that the game rules should be such that the resulting system does start networking, avahi etc. (That's not to say that the goodness metric should be simply the time taken for all services to have started.)
Having game players spend time "do[ing] a lot of damage to X" or changes that break hardware that distributors want to support regardless of boot time, such work isn't useful unless someone does the remaining work of re-adding any of the lost functionality that the distributor considers more valuable than the corresponding reduction in boot time. If there's doubt as to whether anyone would do that work, then maybe the rules shouldn't reward optimizations that do more damage than most distributors would accept; whereas in cases where it is likely that someone else would do the work, then perhaps it's better to reward work on such damaging optimizations than not to have those optimizations.
Different users need different things started up before they can be productive with their machine. The goodness metric for the game can either go for simplicity (choose a common case and optimize that while ignoring all others' needs), or we can try to weight different cases according to their importance to most distributors (which is somewhat arbitrary in choice of weighting, but should result in improvements for more users). We don't have to choose the weights in advance, it's enough for game players to understand that it will be judged by a weighting of the value of the system for different types of users, and that the weighting and judgement of "system value" is intended to reflect real-world values. (Of course there's value in game players being informed about the relative importance of different use cases or how people value boot time compared to lost functionality, but we don't need to specify it all in great detail before a game can begin.)
On the question of delaying login to avoid applications misbehaving when services they need aren't started yet: Note that even the program handling the login might need the network up (for network filesystems or other remote databases) or need setroubleshootd running to debug a problem in that login handler. Maybe some upstart (etc.) ideas can be applied to user applications rather than just init scripts. (Some init replacements work statically, doing a topological sort to determine startup order, whereas other init replacements, possibly including upstart, allow for processes to be started but block on some service coming up.)
Cheating: Not just for Microsoft anymore Posted Sep 23, 2008 17:56 UTC (Tue) by arjan (subscriber, #36785) [Link]
As for services that aren't "up":
* cups -- run from xinetd when being printed to. And no, my netbook isn't a printserver * NFS -- made part of actual first NFS mount * avahi -- sure, can be added. * Networking -- network manager is loaded and started. if there was a network driver for the eee901 it'd have a link in the time. * bluetooth -- the device doesn't have BT.. so no I don't want that service started
(and note that our prototype has about half a second to a second to spare for services you want to add)
As for "login" needing NFS: sure if you configure NFS root, then you'll pay the price for NFS. I don't consider it acceptable that anybody who DOESN'T use NFS root has to pay that price. Even on a generic distro; the distro installer KNOWS nfs root is being used.
So I disagree with you that this isn't applicable to general distributions. General distributions will have to deal with more cases, but they have to, and can, deal with them smartly: only the people who use a feature should pay the price for it in terms of boot time. That doesn't make the distro less generic... and yes it means the distro needs to get several things right, but I consider that fair game.
Again: arjan, .... Posted Sep 25, 2008 17:40 UTC (Thu) by hummassa (subscriber, #307) [Link]
us want linky linky :-) so us can tune our eee701 to boot in 5 seconds too...
:-)
Cheating: Not just for Microsoft anymore Posted Oct 3, 2008 7:50 UTC (Fri) by dgm (subscriber, #49227) [Link]
> only the people who use a feature should pay the price for it in terms of boot time
In fact, this should be applicable to any other system resource: CPU, memory and disk usage.
Cheating: Not just for Microsoft anymore Posted Sep 23, 2008 8:08 UTC (Tue) by farnz (guest, #17727) [Link] That's orthogonal to what Arjan and Auke are doing. You can combine "boot complete in 5 seconds" with "start the desktop before some services are running", to get an even faster boot to the point where you can work (at least in theory - if the critical path is now kernel startup followed by X startup, you're doomed). Plus, the "boot complete in 5 seconds" misses some services I need - my mouse is a bluetooth device, for example, and I use WiFi, both of which have to start after those 5 seconds are up. Also, "boot complete, CPU and disk idle" is a nice objective criteria, that can be measured by tools designed for the job. "Booted to the point where I can work" is not, and invokes the temptation to punt something that's critical for most people's work until after login - for example, with hotplug input device support in X, you could configure a core keyboard, and punt hotplug devices until after X boots. The result is a machine that you can use from the keyboard, but not with a mouse or touchpad - as a keyboard user, that wouldn't stop me working, but it wouldn't be in the spirit of "boot in 5 seconds". Finally, which is actually better for you:
Cheating: Not just for Microsoft anymore Posted Oct 3, 2008 17:25 UTC (Fri) by Janne (guest, #40891) [Link]
I really don't understand this argument. So the machine has not really booted, since network (for example) is not up yet? Well, why should it be? Because you want to use the network right after you get to the desktop? Well, think about it: You get to the desktop, but the network is not yet running. You then decide to launch Firefox. It takes you maybe 2-4 seconds to click the Firefox-icon, it takes anout 2-4 seconds for Firefox to launch, and then it takes you another 2-4 seconds to type in an URL in Firefox. That means that the system has 6-12 additional seconds to bring the network up before you actually NEED to have the network up&running. Network might not be running right after you get to the desktop, but it does not need to be, since it would take you several seconds to actually DO something with the network in any case! Do you need to have networking up if you are not actually using the network for anything?
People who complain about services that are not running right after boot, fail to understand the fact that it takes several seconds for the user to actually DO anything with the system in any case. And that means that the system has quite a bit of time to bring any missing service up before the user actually needs it. Whenever I log in to a machine, I do not launch apps in a split-second or start frantically working right away. No, it takes me quite a few seconds to get up to speed. And the system can use those seconds to load any needed services that are not yet up.
Of course there are wrong ways to do this, like what MS does with XP, where the system is actually un-usable for longish time after you get to the desktop.
Cheating: Not just for Microsoft anymore Posted Oct 3, 2008 19:07 UTC (Fri) by farnz (guest, #17727) [Link] You're missing a lot in your example timeline; let me rework it the way it would actually happen:
Looking at that timeline, one important thing is clear - she has already decided to go to a particular bookmarked website before she touches the power button. All the time taken between her pushing the power button and the website displaying is wasted by the computer. Thus, the only time the OS has free to waste is the time taken by Firefox to start up after the OS has started. Secondly, note that Firefox's start up will be slowed down if the computer is also trying to bring up the network, start printing services and generally do other things at the same time. It's incredibly hard to accurately judge how much idle time you have around application start time. Finally, in my experience, services are not delayed after thinking about use cases. Instead, the delay is based on getting the bare minimum up and running to let me log in, with functionality taking a while to come up after that. Making the challenge "get to idle in 5 seconds" leaves room for someone to come in later, and build on that work to get a "get to usable in 4 seconds, idle in 6", or even a "get to usable in under a second, but idle takes 6 seconds".
Cheating: Not just for Microsoft anymore Posted Oct 3, 2008 19:37 UTC (Fri) by Janne (guest, #40891) [Link]
In your example your wife would have to wait for few second for the network to become functional. Im sorry, but I don't really see that as a big issue. Especially considering the huge benefits users would get in "normal" use-cases.
You are describing a situation where the user is twitching to do something with the computer. Where the user even pre-positions the mouse in order to be able to do stuff as fast as possible. Those cases are very, very rare. Normal users do NOT work like that. Normally people don't start their computers thinking "OMG, I need to get online NOW!". And even if they did, the fact that the system boots in 5 seconds, means that they could get online a lot faster than with "normal" boot-sequence.
That said, I don't really understand the complaing about networking. My OpenSUSE-laptop takes ages to boot. And after it finally get to the desktop, it STILL spends few seconds connecting to the network! It would be A LOT better if it booted in 5 seconds, and then spend few seconds connecting to the network.
It makes sense to exclude networking from this experiment, since connecting to the network is not really part of what we call "booting". It's not up to your computer, it's basically being held back by the network. And hacking the boot-sequence of your computer does not touch your network in any shape or form. Network is completely outside the scope of this test. And just because you do not have working networking for few seconds does not mean that the computer is not usable. And still, the "normal" distros are just as slow as far as networking is concerned, so there are no drawbacks in this experiment, as far as networking is concerned.
So how would your wife benefit if the recipe-machine was using Ubuntu (for example)? Instead of booting in 5 seconds, the machine would boot in 45 seconds. Even if you had fully working networking after that 45 seconds (you wouldn't), it would still take about 30 seconds longer to get online than with this fast booting.
"Secondly, note that Firefox's start up will be slowed down if the computer is also trying to bring up the network"
Starting FIrefox taxes the HD and the CPU. Neither of those are taxed when your NIC is getting an IP-address.
"start printing services"
That could be started when the user actually wants to print. Why should we sit around, twiddling our thumbs, when the system starts printing-subsystem, even though the times we print are few and far between?
Cheating: Not just for Microsoft anymore Posted Oct 4, 2008 11:11 UTC (Sat) by farnz (guest, #17727) [Link] Then you're missing the entire point of the exercise - why does she have to wait 45 seconds for the OS to boot? Why should she be waiting up to a minute for things to be ready to use? Why can't she turn the computer on and use it immediately?In short, why is using a computer with a 1.83GHz Core 2 Duo and 4GB of RAM full of delays, when using an IPTV set top box with typically 100MHz CPU and 32MB RAM is not? Granted, the tasks are different, but the computer is so much more powerful than the STB that it's a fair question. The idea Arjan and Auke were working to is to set a hard challenge - a typical Linux distro takes 30 seconds to get to the same point, they chose 5 seconds - and remove all the obstacles. If you allow delayed service startup to not count, the danger is that you'll discount services that matter to users. Indeed, you're already trying to handwave away an important service for some use cases as "takes too long, and anyway users can wait"; this is exactly why someone doing the challenge must set a defined state in which boot is finished. Given the defined state, I can now look at it, compare it to my use cases, and say "yes, that's good enough", or "no, I need to work out how to fit WiFi startup into that 5 seconds". Again, as I've said several times, you can go from "5 seconds power applied to idle and ready" to "3 seconds power applied to usable, 3 more seconds to idle", and that's a much easier task than going from "60 seconds power applied to idle" to "3 seconds power applied to usable, 120 more seconds to idle. Plus, my experience of normal users is very different to yours - they don't have computers waiting and switched on, they don't start the computer up without a task in mind, they start the computer thinking "Do I have any e-mail waiting?", "Can I look up a recipe to use lemon sole, potatoes and tomatoes?", "What do I need to say in this letter to my bank manager?", "I need to get that proof printed for marking up" and things of that nature. To them, a computer is just a tool; you wouldn't get out your woodworking kit without something to build in mind, so why start up a computer without a job in mind?
Cheating: Not just for Microsoft anymore Posted Oct 7, 2008 12:59 UTC (Tue) by Janne (guest, #40891) [Link]
"why does she have to wait 45 seconds for the OS to boot?"
She doesn't. I mean, you can apparently boot Linux in 5 seconds ;).
"In short, why is using a computer with a 1.83GHz Core 2 Duo and 4GB of RAM
Well, that set-top box is designed to do one thing, and it's designed to do
that said, my DVR takes about 5-10 seconds to boot. My DVD-player takes few
"If you allow delayed service startup to not count, the danger is that
But the thing is that we already have slow as hell boots, even with delayed
In other words: it takes just as long for the two systems to connect to the
And how would you connect to the WiFi befire getting to the desktop? I
"Indeed, you're already trying to handwave away an important service for
But Wifi is not part of what we usually think of when we talk about
"Plus, my experience of normal users is very different to yours - they
Sure. But let's compare two scenarios:
Normal distro:
User turns the computer on. It boots for about 45 seconds, and the user
Arjans EEE:
User turns on the computer. It boots in five seconds. User needs to wait
How is that normal distro handling networking better than the EEE is? It's
removing WiFi from the equation we can focus on the subject at hand:
Cheating: Not just for Microsoft anymore Posted Sep 22, 2008 19:28 UTC (Mon) by madscientist (subscriber, #16861) [Link]
It's true that Ubuntu does do this, but when the Ubuntu folks test boot times they enable auto-login and test the time to boot all the way to a stable, logged-in state.
I have no problem with putting up the login screen as early as possible, since why should I wait until a bunch of background stuff is ready before I can enter my username/password (obviously, if you can't log in yet due to home directories not being present or whatever, then if the system lets me log in to a "broken" state that's a bug)?
But, when testing boot times the number used should be the one Ubuntu folks are using: the time to get from power-on to a fully-settled, functional desktop... NOT to get to the login prompt.
Cheating: Not just for Microsoft anymore Posted Sep 27, 2008 15:22 UTC (Sat) by keybuk (subscriber, #18473) [Link]
Actually, it isn't true.
If you look at the Ubuntu boot sequence, while gdm isn't the last thing
We deliberately don't keep starting services throughout login, because as
Log-in screen Posted Oct 7, 2008 22:41 UTC (Tue) by pgan (guest, #54573) [Link]
The log-in screen should be shown as early as possible (before even X) and should not block the boot process. Thus the computer would be usable earlier, because the boot process would continue while the user is typing her password. This is especially important for users who are slow to authenticate -- some users take about 4 seconds. With a normal boot, they would wait n seconds to see the log-in screen, spend m extra seconds logging in, then wait d seconds till they can use the desktop. If they can authenticate after x second while the computer is booting, they only wait max(n - x, m) + d seconds to use the computer.
With a long boot, this also allows users to authenticate themselves whenever is convenient for them, rather than waiting to do it at the right time for the machine.
And, knowing which user is logging in will allow further parallelization of loading the user's desktop components and services. That will reduce the time "d" required to start up the desktop.
LPC: Booting Linux in five seconds Posted Sep 22, 2008 17:29 UTC (Mon) by salimma (subscriber, #34460) [Link]
Cool beans. Between this and the Ubuntu netbook launcher, which does not have a stable release yet (must be why Dell's netbook is still not shipping if ordered with Linux), we're in for some interesting times on the desktop.
LPC: Booting Linux in five seconds Posted Sep 22, 2008 18:27 UTC (Mon) by flewellyn (subscriber, #5047) [Link]
I don't mean to be a wet blanket, but what benefit does fast booting give us, if we don't boot all that often? If we use suspend to disk, or just keep our machines running, what benefit would we derive from this work? Will it help to improve performance in other ways?
LPC: Booting Linux in five seconds Posted Sep 22, 2008 19:20 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link]
In my mind, suspend is something of a hack to get around awful boot times, and it's still flaky for some users. It also doesn't help you at all when you have to install OS updates that require a reboot.
Sure, suspend has other benefits--you can keep all your applications open where you left off--but starting from a clean system often provides a better user experience, unfortunately. (Fortunately, some of the bigger culprits here, such as Firefox, have fixed their memory leaks. The Firefox-2-GMail leak really sucked.)
LPC: Booting Linux in five seconds Posted Sep 22, 2008 19:25 UTC (Mon) by flewellyn (subscriber, #5047) [Link]
I suppose so. Even so, I'm wondering "what about regular runtime performance? Any benefit there?"
LPC: Booting Linux in five seconds Posted Sep 22, 2008 19:55 UTC (Mon) by Yorick (subscriber, #19241) [Link]
Any serious effort to bring down boot times will inevitably scrutinise each and every daemon and service started and likely do away with a few less essential ones. As a side-effect, that may very well make a system use less resources and be more stable and secure once the system has been brought up.
I also believe that faster boots give us happier and more productive kernel hackers, because they reboot more often than anyone else. That alone makes it worth the trouble.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 7:40 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
> Any serious effort to bring down boot times will inevitably scrutinise
> each and every daemon and service started and likely do away with a few > less essential ones.
Or profile how much users of a system use a particular service and start it by default if they use it a lot, or on demand if they use it occasionally.
LPC: Booting Linux in five seconds Posted Sep 22, 2008 19:58 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link]
Probably not, as it stands.
I suppose a complex application that takes a long time to start in its own right (OpenOffice, I'm looking at you) might take some hints from the methodology and try to parallelize and optimize its startup tasks. I'm not sure how far you get with a userspace app like that though.
I suppose if you have an embedded device that actually gets powered off and on semi-regularly (media player, cell phone), this work directly impacts the user experience. Those devices could actually boot from scratch rather than dumping state to flash for suspend when they power off. That extends flash lifetime, and it makes startup and shutdown quicker.
My current cellphone takes a good 15 seconds to boot. Booting in 5 would be a noticeable improvement. Granted, I only shut it off when I'm flying somewhere or when the battery gets obnoxiously low, but still, it could make you a favorite with the jet setters. Seeing as there's already interesting Linux distributions running on OpenMoko, I'm sure there's plenty of opportunity for cross-pollination. (Check out this one: http://mobile.slashdot.org/article.pl?sid=08/09/21/1730256 )
LPC: Booting Linux in five seconds Posted Sep 22, 2008 20:10 UTC (Mon) by flewellyn (subscriber, #5047) [Link]
Of course, I didn't even think of the impact for an embedded environment. You're right, there's a lot of value there for devices that need to turn on and off regularly.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 3:26 UTC (Tue) by mrshiny (subscriber, #4266) [Link]
Also, suspending is not the same as booting when it comes to your
applications. I can suspend my notebook by closing its lid, and when I come back every single program is exactly where I left it (except for those that depend on network sockets). This is way better than shutting down and rebooting; even apps that support session management don't do that well compared to a nice suspend/resume.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 0:09 UTC (Tue) by rlk (guest, #47505) [Link]
I use suspend as much (or more) because I want to keep everything open with the running state than because of the reboot time. For example, I often have a lot of emacs buffers and xterm windows, and I want that state preserved for as long as possible. I've been known to keep login sessions going for months on end.
With Session Manager, the Firefox annoyances aren't that big of a deal; it's the other stuff I want kept around.
Suspend/resume does not eliminate the need for faster boot time, or vice versa.
suspend vs. reboot Posted Sep 23, 2008 6:31 UTC (Tue) by Cato (subscriber, #7643) [Link]
I greatly prefer being able to suspend/resume - you have all the state of your applications, down to cursor position in documents, history and scrollback in shells, etc. While Linux's session management is very nice it can't replicate all this, so faster boot doesn't help as much as getting suspend working - I usually don't bother trying to make it work as it's quite a hassle compared to hibernate.
I don't find memory leaks an issue these days - Firefox still crashes enough (due to plugins mostly) that it clears out any leaks in any case.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 13:29 UTC (Tue) by lbt (subscriber, #29672) [Link]
> In my mind, suspend is something of a hack to get around awful boot times,
> and it's still flaky for some users. It also doesn't help you at all when > you have to install OS updates that require a reboot.
OK - that's your use...
*I* have 6 virtual desktops, eg:
I have a continually logged on experience interrupted by phone calls, sleep, food, social life, holidays etc - but it's nice to save power at night or when I go for food or go out so I want to hibernate (and I do - I only login/reboot when I choose to upgrade the kernel)
For those who argue that each app should do 'restore state' - why? Debian has what, 22,000 packages many of which would need to be able to restore state. Or we could use hibernate and get them all for free... Hmmm hard choice...
As for "install OS updates that require a reboot." - are you on Linux? This just doesn't happen with any meaningful frequency.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 16:48 UTC (Tue) by bronson (subscriber, #4806) [Link]
Are you talking about suspend or hibernate? Resuming from suspsend takes about 9 seconds on my Thinkpad T42p, while resuming from hibernate takes 1.5 mins. This is unfortunate because cold boot takes less than a minute... I tend to suspend/resume a lot and never ever hibernate.
When Linux supports process suspend/resume, hopefully resuming from hibernate becomes:
I can't wait for containerization to hit.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 18:55 UTC (Tue) by jwb (guest, #15467) [Link]
Why does your resume from suspend take so long? On my ThinkPad it takes less than one second.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 20:18 UTC (Tue) by bronson (subscriber, #4806) [Link]
No idea... The CD-ROM drive spins up (no disk in it though), there's some beeping from the speaker, after 3 seconds the backlight turns on, after 5 it switches to a real video mode, and it spends the last second or so drawing the password dialog.
I don't mind too much, 8 seconds is tolerable. At least it never crashes!
LPC: Booting Linux in five seconds Posted Sep 25, 2008 1:56 UTC (Thu) by deleteme (guest, #49633) [Link]
That's awfully fast, it's more like 1.5 - 3.5 seconds here. The disks starts to spin the screenblinks and take a while to become something usefull-
LPC: Booting Linux in five seconds Posted Sep 25, 2008 2:49 UTC (Thu) by jwb (guest, #15467) [Link]
Well maybe you're right, because I just took a video of my computer waking from sleep and it takes 6 seconds. However, the time between when the backlight comes on and when the unlock dialog appears is a split second. I guess I was mentally attributing the remainder of the time to the hardware/BIOS.
Which brings us back around to the article. The five seconds of booting does not include the time between power-on and when GRUB hands off to Linux.
LPC: Booting Linux in five seconds Posted Sep 26, 2008 2:12 UTC (Fri) by njs (guest, #40338) [Link]
I thought restore from hibernate spent most of its time reading the (potentially multi-gigabyte) memory image from disk. Booting doesn't need to load 500 megabytes of firefox into memory, etc.; is there some reason to think that restoring your individual apps would be faster than restoring the hibernate memory image?
LPC: Booting Linux in five seconds Posted Sep 26, 2008 17:09 UTC (Fri) by bronson (subscriber, #4806) [Link]
Because -- in theory -- you wouldn't have to restore every application, (don't worry about freezing the memory used by all those useless panel apps). And the apps themselves could be smarter (Firefox wouldn't try to persist its in-memory caches). Crash-only apps could just be terminated and re-launched (IM clients, mail clients, etc), no need to write them all out.
I admit, it's all speculation at this point. :)
LPC: Booting Linux in five seconds Posted Sep 23, 2008 17:04 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link]
Ubuntu seems to push kernel updates that want a reboot every few weeks. That said, I usually push it to a couple months before I do reboot.
LPC: Booting Linux in five seconds Posted Sep 22, 2008 20:17 UTC (Mon) by ebirdie (subscriber, #512) [Link]
Together with kernel checkpointing/restart feature, what LWN.net covered in an article a while ago, this could be another possibility to extend battery life ie. when lid closes, checkpoint processes with open file descriptors and below X and shutdown, and then up again in 5 seconds.
At least the fast booting seems to be a simpler way to achieve practically the same goal as the suspend/resume operation has. But the process checkpointing/restarting feature is yet taking its baby steps, so it is practically non-existent. Too bad. I'm haven't found myself comfortable with session features of KDE or Gnome and thus I'm totally relying to suspend/resume to get my desktop back to state, when I left the desktop. And I reboot as seldom as possible - I actually hate system updates requiring reboot or losing the desktop state.
LPC: Booting Linux in five seconds Posted Sep 22, 2008 21:16 UTC (Mon) by anselm (subscriber, #2796) [Link] Why would I want to do suspend-to-disk if I can have a clean boot in five seconds? Waking my machine from the suspend takes way longer than that.
LPC: Booting Linux in five seconds Posted Sep 22, 2008 23:20 UTC (Mon) by nix (subscriber, #2304) [Link]
Your applications might have nonpersistent state you want to preserve.
LPC: Booting Linux in five seconds Posted Sep 22, 2008 23:49 UTC (Mon) by anselm (subscriber, #2796) [Link] That's what I used to think, too. Nowadays most of my applications do a reasonable job of coming up again where I left them before a shutdown, so it's not a big deal.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 0:26 UTC (Tue) by rlk (guest, #47505) [Link]
Emacs doesn't; shell buffers and xterms certainly don't have all their state preserved (possibly megabytes of output, and yes, I do care about that). Much less any background processes I happen to have left running actively (Gutenprint tests, for example).
As I said previously, fast reboot and suspend/resume solve different problems and shouldn't be considered alternatives for each other.
That could be fixed Posted Sep 23, 2008 1:12 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] It would be possible to make Emacs session-aware.
That could be fixed Posted Sep 23, 2008 7:29 UTC (Tue) by nix (subscriber, #2304) [Link]
You'd need to modify a good bit of Lisp (at least you'd need to think of
something to do with process sentinels).
Hm, perhaps a shutdown/restart could appear to the Lisp code like all the
That could be fixed Posted Sep 23, 2008 15:00 UTC (Tue) by shapr (guest, #9077) [Link]
What about emacs desktop? I've been using that for years.
Right now emacs does not save the state of all the open buffers etc until I explicitly exit, but if it saved every minute or so even crashes would have most session state saved.
That could be fixed Posted Sep 23, 2008 15:14 UTC (Tue) by rlk (guest, #47505) [Link]
The issue isn't just open file buffers:
* Shell buffers (input and output history -- including input and output history of the shell, which isn't quite the same thing as the emacs idea of that)
* Command output buffers and other temporary buffers, including *scratch*
* Files that you're looking at that may get changed behind your back that you deliberately haven't reverted yet.
* The state of the lisp world
Obviously, emacs loses all of this if it crashes, but this in the context of choosing to reboot vs. suspend/resume. I'll take my chances on crashes, and I do save my work, but it's still more efficient to keep a session going as long as possible.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 7:54 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
> Nowadays most of my applications do a reasonable job of coming up again
> where I left them before a shutdown, so it's not a big deal.
But they can take an awful long time to do so. Don't know if suspend/resume is faster, because I have never trusted it enough to find out. Perhaps a middle way would be best of all - suspending and resuming individual applications, perhaps even with the application's cooperation.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 8:23 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
Ahem, actually exactly what ebirdie said in a comment further up.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 16:56 UTC (Tue) by s0f4r (subscriber, #52284) [Link]
Please follow this calculation:
Writing on cheap SSD's maxes out at maybe 10MB/sec max., reads at 30MB/sec max sustained. Suppose that you have a laptop with 512mb memory. It will take 51 seconds to suspend to disk. It will take 17 seconds to resume from disk.
suspend to disk is just not the answer :)
LPC: Booting Linux in five seconds Posted Sep 23, 2008 17:05 UTC (Tue) by flewellyn (subscriber, #5047) [Link]
I wouldn't trust an SSD, especially not a cheap one, as a root disk.
Flash life Posted Sep 23, 2008 21:27 UTC (Tue) by man_ls (guest, #15091) [Link] Because of the limited number of rewrites? With 100,000 rewrites and if you suspend 10 times an hour, 8 hours a day your Eee will last 3.5 years. Add some wear levelling, 200,000 rewrites or a half-full memory and you can stop worrying.
Flash life Posted Sep 24, 2008 0:41 UTC (Wed) by flewellyn (subscriber, #5047) [Link]
Yeah, I'd heard that before, but Val Henson wrote a <a href="http://valhenson.livejournal.com/25228.html">blog entry</a> which made a strong counterargument.
Flash life Posted Sep 24, 2008 6:49 UTC (Wed) by man_ls (guest, #15091) [Link] Thanks for the link. It is not so convincing though: even without any wear levelling there is a big safety margin.But if flash memory life really worries you, you can buy an 8GB SD memory card for $20, stick it into your Eee and place the most frequently written-to filesystems (/var, swap) on it. If it ever goes wrong you just replace it (and maybe get a new one for free if inside the 5-year warranty). I have a similar setup and it works fine. Just be sure to buy a fast SD card or suspend will take a long time.
Flash life Posted Sep 25, 2008 1:59 UTC (Thu) by deleteme (guest, #49633) [Link]
I've been running on Compact Flash since 2005 works fine.
LPC: Booting Linux in five seconds Posted Sep 25, 2008 7:27 UTC (Thu) by NCunningham (guest, #6457) [Link]
You're not accounting for compression. Yes, swsusp doesn't do compression, but the other implementations do. You generally get about 50% compression, so half the times for reading and writing.
LPC: Booting Linux in five seconds Posted Sep 22, 2008 19:14 UTC (Mon) by mezcalero (guest, #45103) [Link]
One should note that the Fedora system they showed wasn't actually a complete Fedora system. As mentioned, they removed sendmail. But it doesn't stop there. It didn't have Avahi, or CUPS, or Bluetooth and so on, which makes up a complete Fedora system. I'd have liked to see them actually booting a full system in under 5s.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 0:19 UTC (Tue) by rlk (guest, #47505) [Link]
Different people need different things for a "full system". I don't need Bluetooth at all and Avahi isn't really terribly valuable to me, either (I'm in a pure UNIX/Linux environment where I don't need to worry about file sharing, and otherwise I have a fairly static environment most of the time). I do need CUPS but it's fine if it takes 10-30 seconds more to start; I'm not likely to print as the very first thing I do after boot.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 2:01 UTC (Tue) by arjan (subscriber, #36785) [Link]
We have cups starting from xinetd... on demand
LPC: Booting Linux in five seconds Posted Sep 23, 2008 7:20 UTC (Tue) by rvfh (subscriber, #31018) [Link]
Could you tell us why Sys V init was prefered to upstart? Shouldn't upstart replace xinetd _and_ init _and_ provide faster boot through parallelisation?
Do you think it's possible to boot in 5 seconds with upstart 0.5 or a later version? Or is upstart (partly) going the wrong way?
Please enlighten us, or point us to a blog with your problems/decisions listed :-)
LPC: Booting Linux in five seconds Posted Sep 23, 2008 8:46 UTC (Tue) by arjan (subscriber, #36785) [Link]
First of all, a misconception: Upstart isn't about parallel boot. (This is from discussing a lot with the Upstart author at LPC)
Second: Parallel boot is the wrong technology. It's a good answer to the "I want to boot faster" question, but it's absolutely the wrong answer to the "I want to boot fast" question. Eg it's something that gets you from 45 seconds to 43 seconds.... but not to 5. (note that Fedora 9 already uses Upstart.. and still boots in 45 seconds).
Parallel boot is the wrong thing; it ends up meaning that you're not really doing the critical path in sequential order; but let the system get distracted from that.
Asynchronous boot (where you let the critical path go sequential, and non-critical pieces asynchronous) is the right answer; the article has a graph about this. And Asynchronous boot you can do just fine with SysVinit.... no magic about that.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 9:57 UTC (Tue) by rvfh (subscriber, #31018) [Link]
Thanks a lot!
I can't resist the desire to ask another question: I assume what you were told was that upstart was about event-driven starting/stopping of services, not parallelisation. Does it still make it possible to implement this 5-seconds boot with upstart? Or does upstart get, somehow, in the way?
Thanks for the _very_ useful job you did: some of us still need to boot their machine sometimes ;-)
LPC: Booting Linux in five seconds Posted Sep 23, 2008 17:00 UTC (Tue) by s0f4r (subscriber, #52284) [Link]
It's definately possible to approach the same boot speed with upstart. However, the overhead of reading all the upstart configuration files and doing all the parsing of those is still a bit higher than using plain sysvinit, hence we chose to use that.
This is not a weird choice: several netbook vendors currently do exactly the same thing for bootup.
LPC: Booting Linux in five seconds Posted Sep 25, 2008 7:17 UTC (Thu) by aleXXX (subscriber, #2742) [Link]
Now with all the multicore processors, parallelizing boot should indeed
bring a speedup, shouldn't it ?
Alex
LPC: Booting Linux in five seconds Posted Sep 25, 2008 7:55 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
only if the bottleneck was CPU cycles.
and most of the time it's not.
you have serialization on a lot of things
disk I/O (reading files, searching for the 50 places a config file could be before you find the one where it is, etc)
bus access (you can't query a PCI bus for multiple things at the same time)
timeouts (waiting after sending a command to see if something responds).
timeouts frequently combine with bus access as it may not be safe to do something else until you get a response from the device you just probed for (or decide that it's not really there)
and sometimes you do really have number crunching CPU tasks to do.
multi-core systems make a big difference if you really do have CPU as the limiting factor, but that's usually not the case (and IMHO software that has to do a lot of cpu work to just start up is probably in need of being fixed)
yes, when you get down into the low single-digit bootup range on a relativly slow COU (like the eepc from the talk), you do have to pay attention to the CPU load, but if you have similar systems otherwise, a fast cpu doesn't make that big a difference on a normal distro bootup
LPC: Booting Linux in five seconds Posted Sep 25, 2008 14:39 UTC (Thu) by arjan (subscriber, #36785) [Link]
With multi-core or hyperthreading it is worth doing some things asynchronous.
But it's a subtle but important difference between doing things in parallel and doing some selected things asynchronous.
The key thing is to do the "critical path" of the boot sequential and as tightly packed as possible, while doing non-critical (to the boot) things asynchronous.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 20:19 UTC (Tue) by mezcalero (guest, #45103) [Link]
That doesn't really work. CUPS without the browsing is not really useful. And for the browsing you need to run it continuously all the time. Much like Avahi.
It's nice to be able to boot in 5s, but this is far from a standard Fedora system. Be honest!
LPC: Booting Linux in five seconds Posted Sep 23, 2008 20:27 UTC (Tue) by rlk (guest, #47505) [Link]
As I said before, not everyone needs browsing -- a lot of people are in more or less static environments where the topology never changes. There's no reason why those people should be burdened by the overhead of network browsing.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 21:30 UTC (Tue) by nix (subscriber, #2304) [Link]
Exactly. I have one printer, and it's connected to one machine. Why do I
need browsing?
(How many people not using laptops have multiple printers anyway? Is it
LPC: Booting Linux in five seconds Posted Sep 23, 2008 22:02 UTC (Tue) by foom (subscriber, #14868) [Link] Actually, modern Cups actually uses dns-sd for printer discovery instead of special broadcast messages, so it no longer needs to be continuously running to receive the broadcasts: avahi will handily take care of that part. Yay consolidation.
LPC: Booting Linux in five seconds Posted Sep 25, 2008 15:39 UTC (Thu) by msmeissn (subscriber, #13641) [Link]
CUPS does printer autodiscovery (zeroconf style, but on other ports), so
some people want it running to find printers. :/
And it manages local queues occasionaly, which was one reason I heard to
Ciao, Marcus
LPC: Booting Linux in five seconds Posted Sep 27, 2008 15:27 UTC (Sat) by keybuk (subscriber, #18473) [Link]
Although according to your boot chart, you're not starting xinetd either ;)
Starting CUPS on demand isn't quite ideal sadly, if the user is using
Sadly we can't "start CUPS 30s before the user needs it" ;)
Though I entirely agree in principle that CUPS is not part of the critical
The most ideal way to deal with these kinds of services is to start them
That way, if the user clicks print and cups wasn't running yet, it gets
Of course, even better would be if we could do network printer discovery
LPC: Booting Linux in five seconds Posted Oct 2, 2008 8:36 UTC (Thu) by renox (subscriber, #23785) [Link]
Agreed, I understand the desire to do 'booting in 5s' without cheating, but CUPS is probably one exception here where cheating is okay:
1) it's unlikely to take much CPU or IO load (if it does then it's a bug) so starting it in the background won't be felt as a slowdown for the user.
2) users are unlikely to print just after starting the computer so launching the desktop before CUPS is okay.
3) the critical part for the user here is the 'time to print' if having to find a network printer really slow downs printing then it make sense to have CUPS running all the time, not on demand.
LPC: Booting Linux in five seconds Posted Sep 22, 2008 19:43 UTC (Mon) by SimonKagstrom (subscriber, #49801) [Link]
Before someone else says it: Excellent article Don, very well written!
// Simon
LPC: Booting Linux in five seconds Posted Sep 22, 2008 19:56 UTC (Mon) by arekkusu (subscriber, #54092) [Link]
Interesting Article! And impressive performance !
I am not up to the technical detail but basically it look like there are quiet a lot of optimisation to do. I hope a lot can be done to do generalize optimisation and not just for customized for some system. Definitely "sendmail"(...) should be be loaded by default.
I was wandering how much the SSD helped on the Eeepc. SSD should be good on boot because of the very fast access time. However the SSD on the EEPC is rather on the cheap side, not that fast compare to the high-end (100MB/s range).
LPC: Booting Linux in five seconds Posted Sep 22, 2008 20:32 UTC (Mon) by nix (subscriber, #2304) [Link]
Well, some disk interfaces would have ruined any chance of booting in 5s.
SCSI takes so long to start that you can start it asynchronously, but even then it can't give you userspace (even the initramfs) until SCSI's up. (I think it takes 10s on my machine with four disks in a rather old sym53x875: maybe newer controllers are faster?)
More blockdev-related slowdowns that spring to mind: back in the early
Using LVM, if you're vgscanning it is of course going to be slower than
LPC: Booting Linux in five seconds Posted Sep 22, 2008 23:25 UTC (Mon) by jwb (guest, #15467) [Link]
I wondered the same thing. I put a Samsung SLC SSD in my ThinkPad and the cost of reading a random page is hardly any slower than the cost of reading sequential pages, so the benefit of the linear readahead is small. But it's still a lot slower than RAM, so if you can page it in ahead of time while the CPU is busy, you can still benefit.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 10:56 UTC (Tue) by spaetz (subscriber, #32870) [Link]
>Definitely "sendmail"(...) should be be loaded by default.
Why is that? Some people might want it, but many won't. I know, I don't need it.
fetchmail feature Posted Sep 23, 2008 13:29 UTC (Tue) by dmarti (subscriber, #11625) [Link] The Fetchmail POP client used to deliver to the system SMTP daemon by default, so you needed sendmail running before you could check your mail. Now the preferred alternative seems to be either a desktop all-in-one mail program, or OfflineIMAP.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 17:03 UTC (Tue) by s0f4r (subscriber, #52284) [Link]
Don't make 99% of all the users pay for something only you use. Sendmail does really not belong on netbooks and for those who really want to have it there: you can still start it manually. No netbook vendor should ship sendmail enabled by default.
LPC: Booting Linux in five seconds Posted Sep 24, 2008 7:26 UTC (Wed) by ttonino (subscriber, #4073) [Link]
No server vendor should enable Sendmail as daemon by default either. Accepting mail on port 25 is uncommon. Sending out mail isn't, but it is done on demand with Sendmail from the command line. What cannot be sent can be pushed out with a cron job that does a sendmail -q every now and then.
LPC: Booting Linux in five seconds Posted Sep 22, 2008 20:26 UTC (Mon) by alspnost (guest, #2763) [Link] Great work - and seeing the fruits of this in normal distributions cannot come a moment too soon. It's laughable that my 64-bit dual-core beast of a machine still takes longer to boot our favourite efficient, modular OS than my 166MHz Pentium took to boot Windoze in 1996.Let's declare war on bloat and get the majority out-of-the-box Linux desktops booting in <5 seconds! No-one cares if servers take a few minutes to boot, but this article highlights some of the silliness occurring with humble netbooks. Mind you, I did wonder about buying another cheap netbook and using it as a lightweight home server :-)
LPC: Booting Linux in five seconds Posted Sep 23, 2008 6:56 UTC (Tue) by man_ls (guest, #15091) [Link] Well, not all that "bloat" is bad. udev, for example, is a great invention; we probably don't want to create static /dev's for every laptop out there (I know I don't). And I don't really care if it's 5 or 15 seconds, so there is a lot of margin for adding such things back. But trimming the boot fat is still excellent news. Let's hope these improvements trickle down soon!
LPC: Booting Linux in five seconds Posted Sep 23, 2008 8:31 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
But if you are loading a kernel which has compiled-in support for a minimal hardware base, you can provide static /dev entries for just that hardware. udev was loaded later anyway if I read correctly. Actually, you could even have several such minimal kernels for different configurations and decide in advance which to load.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 7:15 UTC (Tue) by njs (guest, #40338) [Link]
> No-one cares if servers take a few minutes to boot
Just FYI, historically servers have driven a lot of the, for instance, hardware changes necessary to get fast boot (ever noticed that default POST started skipping a number of mostly-useless checks in the last few years?). Mostly because people wanted be able to write big enterprise contracts saying "the server will be up 99.999% of the time", which gives you 5.2 minutes downtime per year, and if one reboot blows your yearly downtime budget, well...
(As far as I know no-one no-one cares about +-minute of reboot time in practice and the whole 99.999% thing is largely a gimmick, but you need it to be Marketing Compliant(TM), and apparently that's enough to drive BIOS changes etc. And hey, faster boots for us.)
LPC: Booting Linux in five seconds Posted Sep 25, 2008 15:01 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
I don't know which servers you're looking at, but I generally find them to be relatively slow to boot. Whereas Microsoft has made fast booting (from the BIOS to the Windows loader) a requirement for putting the Windows logo on desktops and laptops.
Video is available on youtube Posted Sep 22, 2008 20:53 UTC (Mon) by arjan (subscriber, #36785) [Link]
just finished uploading the video of the fast booting laptop we used (for those in the room who couldn't see the netbooks)
Video is available on youtube Posted Sep 22, 2008 21:28 UTC (Mon) by bronson (subscriber, #4806) [Link]
That is an awesome video. I understand quantitatively how fast 5 seconds is but there's nothing quite like actually watching it. Love how the desktop smashes into existence at the very last second.
Any chance of getting this to work on the OLPC...? Since its power saving hasn't lived up to the promises, booting it fast would be very very handy.
Video is available on youtube Posted Sep 23, 2008 13:24 UTC (Tue) by kjp (guest, #39639) [Link]
*mind blows*
How much does Readahead help the SSD?
Benefit of sReadAhead on SSD Posted Sep 23, 2008 14:49 UTC (Tue) by jreiser (subscriber, #11027) [Link]
A little less than 3 seconds (75MB of data at 25MB/s). The CPU and the SSD are both always busy from t=1.02 to t=4 seconds. The transfer latency is almost completely hidden, whereas before there was little overlap. Compare the bootcharts.
Video is available on youtube Posted Sep 23, 2008 21:41 UTC (Tue) by arjan (subscriber, #36785) [Link]
it helps a little over 2 seconds; might sound little but remember that this is for a 4 second userspace part of the boot...
Now what about shutdown? Posted Sep 22, 2008 22:21 UTC (Mon) by Felix_the_Mac (guest, #32242) [Link]
This is fantastic, it really throws down the gauntlet to every distribution.
If we can boot in 5 seconds surely we should be able to shutdown in less?
Now what about shutdown? Posted Sep 22, 2008 22:48 UTC (Mon) by drag (subscriber, #31333) [Link]
Well if the applications are designed correctly then you can reduce the shutdown time to a few msec.
So the applications should be designed that at any time they can have the power cut and not lose data. You could have a 'shutdown' thread in the kernel that does the equivalent of (in psuedo-shell):
killall * && sync && acpi-poweroff
----------
For example; Say your editing a file and Vim caught a shutdown message then it wouldn't bother you with the details. It would simply double check that the last change you've made was committed to a temporary file on disk (which should of already been done if you were gone long enough to navigate to the shutdown button) and just die.
Next time you start up Vim you go right back to your edit. It does this mostly already.
I can send a killall -9 epiphany-browser and when I open the browser again it just starts me off were it left off. That's what it does now.
Similar things for OO.org and most other decent applications that I use. They don't need some complicated shutdown procedure.. just tell them to die, and then pull the power.
Just crash. Posted Sep 23, 2008 1:16 UTC (Tue) by dmarti (subscriber, #11625) [Link] Val Henson did a related LWN piece on Crash-only software. You have to write crash recovery anyway, so why not "crash" every time?
Now what about shutdown? Posted Sep 23, 2008 1:16 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] Val Henson wrote an article about that for LWN: Link.The observation was that it often takes less time to crash and restart a program than it does to shut it down cleanly. So why not always crash it?
Now what about shutdown? Posted Sep 23, 2008 7:31 UTC (Tue) by nix (subscriber, #2304) [Link]
Because programs that crash are not necessarily in a consistent state, so
crash recovery can fail where ordinary bootups do not. (Of course, if you can make crash recovery reliable with something like application-level journalling, your point stands, unless like databases the post-crash bootup is really expensive. But that's probably a rare case.)
Other fun features for "crashable" apps Posted Sep 25, 2008 14:59 UTC (Thu) by dmarti (subscriber, #11625) [Link] Programs that come back in a messed-up state after a crash make baby Jesus cry. The vi clone "elvis" had good recovery very early, and we have enough disk space now to do it even for very large media files.A user actions log that an app could replay might have other uses, too. Of course there's deep undo and bug reporting, and automatic macro writing by identifying common steps might be useful. There was even a legal case a few years ago where a composer couldn't prove he had created a certain audio file, because he couldn't put the sliders of his GUI audio app on the exact right pixel.
Now what about shutdown? Posted Sep 23, 2008 3:11 UTC (Tue) by arjan (subscriber, #36785) [Link]
So far we found one bottleneck in shutdown: all the dirty pagecache data needs to be flushed to the disk before we can power off, and some of the SSDs and disks out there are just not very fast.. this can take several seconds easily.
Now what about shutdown? Posted Sep 25, 2008 15:13 UTC (Thu) by dmarti (subscriber, #11625) [Link] If the app really needed that data it would have called fsync a while ago -- so just halt. Applications are going to have to be able to handle coming back after a kernel panic or a kicked-out power cord anyway.
Now what about shutdown? Posted Sep 26, 2008 2:24 UTC (Fri) by njs (guest, #40338) [Link]
Uh... so if I hit "save" while using my app, that app should always fsync before returning? That sounds awful. (I guess the alternative is that we just throw away the files that users thought they had saved, but that seems suboptimal.)
IIRC emacs (used to?) do this by default, and until I disabled that it was unusable on a laptop, because hitting C-x C-s blocked everything for a few seconds waiting for the drive to spin up. ELISP SMASH
When is "save" really "maybe save"? Posted Sep 26, 2008 15:05 UTC (Fri) by dmarti (subscriber, #11625) [Link] Applications could be smart about this. The answer might be something like: fsync on save if 100 user actions or 10s of CPU time have been spent on the file since the last save. Or fsync on save if the file has gone from a broken state (invalid HTML, spelling errors, audio that clips, program that won't compile) to a fixed state.(And you could always do the fsync in a separate thread or process, so the app is responsive again.)
When is "save" really "maybe save"? Posted Sep 26, 2008 21:43 UTC (Fri) by njs (guest, #40338) [Link]
fsync doesn't mean "hey kernel actually write this to disk", it means "write this to disk *now*" (and in practice, "write everything to disk *now*", because our filesystems are not that great). If you're running it async, then you get exactly the same semantics as a plain write. The kernel already guarantees that stuff will be written to disk within n seconds, with n a tweakable parameter that's important for power saving. I guess I just don't see the advantages of moving that to a million per-app settings, all using an inappropriate interface.
If the goal is to reach a point where we can throw away a lot of data instead of flushing it to disk at shutdown, then this approach is making a classic mistake: it's trying to mark everything that *does* need to go to disk, and hoping that eventually everything will be marked and we'll be able to flip the switch and throw everything else away. The better approach is to mark stuff that isn't important, like some fcntl to request "power-loss semantics" for writes to some file; then you could get some win immediately, and expand it incrementally over time.
I doubt this is easy or important enough to actually get the coordinated effort needed to implement it, but that's how I'd do it...
Now what about shutdown? Posted Sep 23, 2008 17:09 UTC (Tue) by s0f4r (subscriber, #52284) [Link]
So far we've seen large jitter in shutdown times - varying from 3 to well over 10 seconds. Shutdown is a really hard case for optimization as we have no idea what threads are going to be woken up and perform work when we killall9, and thus it's extremely unpredictable.
We so try to send a sync() as early as we possibly can to the system to remove some of this load, which seem to help.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 0:36 UTC (Tue) by csawtell (guest, #986) [Link] While getting a lappie to boot in 5 seconds is quite an achievement, what I'd really like to see is my ThinkPad waking up from the suspend state almost instantaneously. Currently it takes about 8 seconds from opening the lid to a usable desktop.Any chance of doing that?
LPC: Booting Linux in five seconds Posted Sep 23, 2008 1:14 UTC (Tue) by dmarti (subscriber, #11625) [Link] What kernel are you running? I had slow wakeups on an X61 but it went away some time before 2.6.26.5.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 8:53 UTC (Tue) by k3ninho (subscriber, #50375) [Link]
How much RAM do you have and how fast is your disk? At best, 1GiB of Ram read at 60MiB per second will take 16ish seconds. If you manage some compression and only take the parts of memory used in running programs, you'll speed things up. But almost-instantaneous will be IO bound by your disk.
K3n.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 10:05 UTC (Tue) by rvfh (subscriber, #31018) [Link]
I assume he meant wake up from suspend-to-ram...
LPC: Booting Linux in five seconds Posted Sep 23, 2008 21:22 UTC (Tue) by csawtell (guest, #986) [Link]
> I assume he meant wake up from suspend-to-ram...
He did.
No moss Posted Sep 23, 2008 2:33 UTC (Tue) by jreiser (subscriber, #11027) [Link] The work was done nearly just-in-time, too. The call for papers closed July 31, the conference was Sept. 16-19. "We're so annoyed that between the time of submission and the plumbers conference, we will make our netbooks boot in 5 seconds, and even talk about how we did it." Auke said that video was made the night before the presentation.
No moss Posted Sep 23, 2008 17:10 UTC (Tue) by s0f4r (subscriber, #52284) [Link]
I don't recall saying that :)
The video was shot about one week before the conference, not the evening before :)
Hat's off to tux Posted Sep 23, 2008 4:42 UTC (Tue) by salinuxam (guest, #50554) [Link]
Excellent piece of work :) Nice to see it all happening in 5 seconds.. I think debian always tried to follow this... :)
SPLASH! Posted Sep 23, 2008 5:42 UTC (Tue) by eru (subscriber, #2753) [Link] The development time that distributions spend on splash screens is much more than the Intel team spent on booting fast enough not to need one.That one goes to my quotes file... I, too, am mystified by this splash screen fashion: If starting up something really takes an unavoidably long time, it is far better to scribble status messages about what is really going on. It keeps the user (even a nontechnical user) better entertained than staring at some pretentious attempt at graphics design, and can be useful for troubleshooting. (Also for the nontechnical user, when he phones his friendly hacker after the the start-up freezes for some reason.)
SPLASH! Posted Sep 25, 2008 7:58 UTC (Thu) by cdamian (subscriber, #1271) [Link]
I wonder if the new flicker free boot screen for fedora 10 will make things faster or slower. I sounds like a lot of work for something we don't want to see anyway.
X11 and CC? Posted Sep 23, 2008 6:14 UTC (Tue) by eru (subscriber, #2753) [Link] The X Window System runs the C preprocessor and compiler on startup, in order to build its keyboard mappings.Sounds very strange. Frankly I did not know it does this. Mapping keyboard presses to X's internal codes isn't exactly time-critical, so why doesn't it simply use a mapping table (or some kind of bytecode if a simple table is not powerful enough) loaded from a binary file? Using CC for this sounds like something done just for the hack value...
X11 and CC? Posted Sep 23, 2008 7:34 UTC (Tue) by nix (subscriber, #2304) [Link]
It's not compiling anything: it's passing the keysym files through the C
preprocessor before xkbcomping them. Everyone hates this (it's imake only not quite as ugly). I'm not sure if the rip-out-xkbcomp-at-every-X-start job is done yet, but it's definitely on people's lists
X11 and CC? Posted Sep 23, 2008 17:12 UTC (Tue) by s0f4r (subscriber, #52284) [Link]
there is a patch and it'll likely be in git soon, we sent it to Keith P. :)
X11 and CC? Posted Sep 23, 2008 20:10 UTC (Tue) by nix (subscriber, #2304) [Link]
YAY! Another ugly crock bites the dust...
(of course we still need /lib/cpp for the occasional non-X program that
Splash screens and initramdisk Posted Sep 23, 2008 8:45 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
It should be possible to improve the look of the kernel boot without going to the lengths that Ubuntu or Fedora's splash screens do. The splash can use the console instead of a custom graphics setup, the graphic logo can be put there by the boot loader and left where it is, and if the boot is that fast, I'm sure no one will mind a "Starting [distro name]", dot, dot, dot instead of a progress bar. And of course that makes it easier to display any fatal messages without spoiling the general esthetics :) Non-fatal messages should not be shown on the console by default of course.
On a different subject, couldn't an initramdisk actually speed up booting from hard disk if done right - by just caching all the stuff which must be read to boot in a single file, which can be read with a single hard disk seek?
Splash screens and initramdisk Posted Sep 23, 2008 9:53 UTC (Tue) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]
> Non-fatal messages should not be shown on the console by default of course.
Even if the only retribution the software writers ask for is a copyright line?
Splash screens and initramdisk Posted Sep 23, 2008 10:04 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
Those things are hidden by bootsplashes even today. But even if they weren't, how do you get around the problem of several hundred lines of attributions and notifications going past in a few seconds? That will not help the people wanting recognition.
Splash screens and initramdisk Posted Sep 23, 2008 13:26 UTC (Tue) by Cato (subscriber, #7643) [Link]
Putting everything in an initramdisk is really optimising for hard disks, which have slow random I/Os. SSDs don't have this problem, so it's better to find an optimisation that works for them too.
Splash screens and initramdisk Posted Sep 23, 2008 13:31 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
Wouldn't an alternative be to optimise for the system you are running on, assuming that on the whole it will not change much from one boot to the next? And if it does change, you use the slower fallback for that boot.
Splash screens and initramdisk Posted Sep 24, 2008 8:57 UTC (Wed) by maney (subscriber, #12630) [Link] Hmmmm... Isn't that what Windows does, though without any very useful fallback when it fails?
Splash screens and initramdisk Posted Sep 23, 2008 17:14 UTC (Tue) by s0f4r (subscriber, #52284) [Link]
Not really. The overhead of actually loading the ramdisk using the slowest read method (BIOS) the system has available is extremely expensive. Once the kernel is booted we can use the fastest methods to read the disk.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 12:24 UTC (Tue) by MisterIO (guest, #36192) [Link]
I'm sorry, but I don't really see the benefit here. It's just 45 seconds! I actually consider this effort a waste of time! If it were from 4 minutes to 45 seconds, I'd have appreciated it, but just 45 seconds are more than acceptable!
LPC: Booting Linux in five seconds Posted Sep 23, 2008 17:20 UTC (Tue) by s0f4r (subscriber, #52284) [Link]
You can't save more power than a device that's off...
That said, how about a linux-based phone that is completely powered off and wakes up when it's called? Would you want to have the caller hold for 45 seconds while your OS boots to start a voicemail application?
Think about servers with a 99.999% uptime guarantee. with a 5 second shutdown and startup they can be rebooted 20x a year. with a 45 second shutdown and startup you can reboot them twice a year.
You obviously haven't used a computer that boots in 5 seconds yet. I guarantee that when you do, you will never want the old 45 second boot again :)
LPC: Booting Linux in five seconds Posted Sep 23, 2008 22:12 UTC (Tue) by MisterIO (guest, #36192) [Link]
Well, maybe you're right. We'll see. If it works out without any side effect, it'll be good anyway.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 13:00 UTC (Tue) by jpmcc (guest, #2452) [Link]
Why boot? why suspend? I have two mobile devices, a Palm TX and an Eee PC. The Palm is effectively always on - that's the real prize Linux hackers should be aiming for.
John
LPC: Booting Linux in five seconds Posted Sep 23, 2008 13:39 UTC (Tue) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]
If you have a software loaded using a library (for instance Glibc), then you upgrade the Glibc package, only the file on disk is updated, and only the application newly created will use this new file.
Linux do not provide re-loading current tasks with the new libraries; during the time in between the library is upgraded and all the old users of the old library have disappered, the library file is twice is memory - and old programs will still contain bugs of the old library. Debian seems to be good at restarting services when their dependancies are upgraded, but I am not sure they handle things like Glibc upgrade. That is why booting from scratch is needed from times to times.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 17:43 UTC (Tue) by hmh (subscriber, #3838) [Link]
Yes, Debian deals with glibc upgrades. But nothing is really perfect, it is best to just check for old libs in memory after an upgrade:
lsof +L1 | grep lib
together with
lsof -n | grep 'path inode' | grep lib
will give you that info, for example.
LPC: Booting Linux in five seconds Posted Oct 3, 2008 11:03 UTC (Fri) by pabs (subscriber, #43278) [Link]
A better way to do that is:
apt-get install debian-goodies ; checkrestart -v
That gives you package names and init scripts to run.
LPC: Booting Linux in five seconds Posted Sep 23, 2008 18:12 UTC (Tue) by arjan (subscriber, #36785) [Link]
the FAA and TSA are 3 letter agencies that tend to make you turn off your devices.... just as an example
not booting is obviously faster as any type of boot, no argument about that. The good news is that there's no exclusivity between the two.
LPC: Booting Linux in five seconds Posted Sep 25, 2008 16:18 UTC (Thu) by kamil (subscriber, #3802) [Link]
My understanding is that the logic behind turning off your laptop during the take off/landing is not about electronic interference, but more about you being alert to what's going on on board. Also keep in mind that they don't just ask you to turn them off, but also to stow them. They simply don't want anything to obstruct the escape routes in case of an emergency, including any wires around your head.
What I'm trying to say here is that in practice, suspending your laptop during take off/landing as opposed to turning it off is perfectly fine. Your average flight attendant will likely flatly deny that when asked, but those people are not paid to think...
LPC: Booting Linux in five seconds Posted Sep 30, 2008 21:27 UTC (Tue) by salimma (subscriber, #34460) [Link]
And given that you don't really hear a chorus of start-up chimes from business travelers' laptops once the electronics gag has been lifted, that's obviously what they've been doing all along: suspending.
Nobody fully turns off their PDAs too, as far as I can tell. Though you hope they do remember to put them to in-flight mode...
LPC: Booting Linux in five seconds Posted Sep 24, 2008 17:58 UTC (Wed) by xed (guest, #52285) [Link]
I very much appreciate the work that has been put into this. Just like the eee showed the world that a little cheap computer was possible (and, as a bonus, that Linux was possible even for normal folks) now, this shows that fast boots are possible. Maybe people will consider this goal to be more interesting and desirable. It certainly is for me. I currently use ratpoison on my eee because of the screen space and interface issues, but I do love the *much* faster boot cycle. I remember the computers of the 80's where you turn on the power switch and they were ready before you were.They were silent too...
LPC: Booting Linux in five seconds Posted Sep 25, 2008 8:34 UTC (Thu) by phillemann (guest, #49231) [Link]
I don't quite unterstand what the "desktop environment" means in the context of boot time. It obviously gets 2 seconds in the 5 second boot time, so a large part.
Is it the initialization of xfce (or even KDE which should take even longer)? If so, using a window manager like, fluxbox/ion/xmonad could save even more time.
LPC: Booting Linux in five seconds Posted Sep 25, 2008 14:24 UTC (Thu) by nix (subscriber, #2304) [Link]
As an example, X on my rather old 2001-vintage system takes seven seconds
from typing 'startx' through to the display stabilizing and .Xinitrc beginning to be executed.
That's a *long* time to change video mode.
LPC: Booting Linux in five seconds Posted Sep 25, 2008 14:56 UTC (Thu) by arjan (subscriber, #36785) [Link]
It's from the start of the desktop environment (in our case XFCE) until it's done (in the "screen painted, cpu and disk idle" sense).
Yes 2 seconds is very generous and more minimalistic desktops can go much faster than that. We decided to pick XFCE since, well, first of all, we could hack the code as kernel guys, and second, it has a feature set that at least is close to what the "big guys" do (which code we didn't feel we could hack as kernel guys).
Can XFCE go faster than 2 seconds? probably. We met our budget for it after one small patch so we stopped working on it and focused on other parts instead.
This may sound weird but our project really was about booting in 5 seconds, not about booting fast or fastest ;-).... we engineered it budget driven, which really helped us to spend our time effectively, specifically, on those parts of the boot process that were over budget, rather than getting bogged down in one part and spend 3 seeks making it go from 2.0 to 1.9 seconds.
Filesystem optimization? Posted Sep 25, 2008 11:24 UTC (Thu) by mlankhorst (subscriber, #52260) [Link]
What this article makes me interested in is doing the same for traditional
hard disks. You could make an extension in ext4 that will reserve some space for sReadAhead which contains only the useful parts of files and a special index that says what data is in there. If ext4 will read during boot time that index and the subsequent data you would have read all data needed during boot and io would no longer be an issue.
LPC: Booting Linux in five seconds Posted Sep 26, 2008 0:41 UTC (Fri) by Hawke (subscriber, #6978) [Link]
So why aren't these optimizations being done "for real", with the intent of being packaged for normal distros? It's great to know that in theory it can be done, but it's of little benefit if no one actually does it...
They are Posted Sep 26, 2008 13:42 UTC (Fri) by dmarti (subscriber, #11625) [Link] Actually, this stuff does look like it's on the way to becoming "real." Ted Ts'o and Keith Packard (filesystem and X) were in the crowd, and both sounded interested in accepting this work, or something based on it, into the "real" versions of the software. The actual readahead program is supposed to be on the Moblin site soon -- so Fedora, Ubuntu and the rest can download and integrate it if they want to.
Are the .config available Posted Oct 3, 2008 13:32 UTC (Fri) by ummmwhat (guest, #54087) [Link]
Hi, I just want to know if you can post the .config of your presentation's kernel.
Thanks in advance.
Best regards...
LPC: Booting Linux in five seconds Posted Sep 30, 2008 16:37 UTC (Tue) by syntropy (guest, #54409) [Link] I have been booting in a rough eight seconds (GRUB->X) for months without the problematic issues of readahead and deferring startup to the 'background'. My system is loaded and synchronized in 8 seconds flat, without tearing out subsystems and destroying so many internals and hacks on Fedora.Kyuba.
LPC: Booting Linux in five seconds Posted Oct 2, 2008 12:13 UTC (Thu) by jwmittag (guest, #43097) [Link] Some time ago there was this MachBoot Linux Live-CD (read "Mach" as in "Supersonic Speed", not as in "Research Microkernel obsoleted 20 years ago and only kept alive by Apple and Hurd"). Their current record is 5.68s, which is pretty darn fast considering that CD-ROMs are both slow and have absolutely abysmal seek times. Interesting times …
LPC: Booting Linux in five seconds Posted Oct 3, 2008 7:44 UTC (Fri) by jordoex (guest, #54491) [Link]
Looks like Ubuntu has some work to do for Jaunty Jackalope if they want to impress anybody now!
message output Posted Oct 3, 2008 12:48 UTC (Fri) by reed (guest, #54499) [Link]
I noticed from your video that there is a minimum of message printouts on the console. Output takes a lot of time, especially when there's such a flood of it, and it's easy to forget about.
LinuxBIOS / CoreBoot Posted Oct 6, 2008 10:58 UTC (Mon) by endecotp (guest, #36428) [Link]
How much more time could we save by booting using CoreBoot (aka LinuxBIOS) instead of the manufacturer's supplied BIOS ROM?
I can start my 1978 Ford Pinto in 4 seconds Posted Oct 6, 2008 18:32 UTC (Mon) by gumby (guest, #54545) [Link]
Providing its not to cold, I can turn ignition to start, fire up the cylinders put car in gear put foot on the gas, let clutch out in 4 seconds on a good day.
Why are computers so slow at starting, maybe it takes them a while to warm up and get those electrons flowing.
I can start my 1978 Ford Pinto in 4 seconds Posted Oct 6, 2008 20:46 UTC (Mon) by nix (subscriber, #2304) [Link]
Thank you for completing this discussion by providing the obligatory
Stupid Car Analogy(TM). (It is well known that all computing discussions must eventually include a stupid and inappropriate analogy to the automobile.)
I can start my 1978 Ford Pinto in 4 seconds Posted Oct 8, 2008 3:31 UTC (Wed) by pgan (guest, #54573) [Link]
Well, using analogies is like two eggs sunny-side-up, flying through space.
LPC: Booting Linux in five seconds Posted Oct 20, 2008 11:04 UTC (Mon) by skeldoy (guest, #54795) [Link]
I got a custom OS built on the latest vanilla kernel and busybox to boot in 10 seconds without changing any code - it hardly does anything - I just wondered where you get you 5 extra seconds from. It has to be the kernel - my initrd and x-startup (all parallel except network) takes less than a second, so all the time that is spent is in the kernel.
I just wondered what kind of stuff you did to the kernel to make it boot faster. Is there some smart stuff we can do to tweak it? Are some of the options real time consuming? Can you post a link to the .config?
LPC: Booting Linux in five seconds Posted Nov 5, 2008 21:10 UTC (Wed) by tholme (guest, #54306) [Link] He got rid of the initrd and made som changes to the kernel. You can find them in his fastboot.git-tree
|
|||||||||||||
![[Fedora bootchart]](/images/fastboot/fastboot-f1_sm.png)
![[Ubuntu bootchart]](/images/fastboot/fastboot-f2_sm.png)
![[Asynchronous hardware
init]](/images/fastboot/fastboot-f3_sm.png)
![[Parallel tasks]](/images/fastboot/fastboot-f4_sm.png)
![[5 second boot]](/images/fastboot/fastboot-f5_sm.png)