LPC: Booting Linux in five seconds
Please consider subscribing to LWNSubscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.
At 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.
|
| Figure 1 |
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.
|
| Figure 2 |
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 kernel
Step 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.
|
| Figure 3 |
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 init
Fedora 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).
|
| Figure 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.
|
| Figure 5 |
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| Index entries for this article | |
|---|---|
| Kernel | Bootstrap process |
| Kernel | Fast booting |
| GuestArticles | Marti, Don |
| Conference | Linux Plumbers Conference/2008 |
Posted Sep 23, 2008 6:56 UTC (Tue)
by man_ls (guest, #15091)
[Link] (1 responses)
Posted Sep 23, 2008 8:31 UTC (Tue)
by mjthayer (guest, #39183)
[Link]
Posted Sep 23, 2008 7:15 UTC (Tue)
by njs (subscriber, #40338)
[Link] (1 responses)
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.)
Posted Sep 25, 2008 15:01 UTC (Thu)
by BenHutchings (subscriber, #37955)
[Link]
Posted Sep 22, 2008 20:53 UTC (Mon)
by arjan (subscriber, #36785)
[Link] (4 responses)
Posted Sep 22, 2008 21:28 UTC (Mon)
by bronson (subscriber, #4806)
[Link]
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.
Posted Sep 23, 2008 13:24 UTC (Tue)
by kjp (guest, #39639)
[Link] (2 responses)
How much does Readahead help the SSD?
Posted Sep 23, 2008 14:49 UTC (Tue)
by jreiser (subscriber, #11027)
[Link]
Posted Sep 23, 2008 21:41 UTC (Tue)
by arjan (subscriber, #36785)
[Link]
Posted Sep 22, 2008 22:21 UTC (Mon)
by Felix_the_Mac (guest, #32242)
[Link] (11 responses)
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?
Posted Sep 22, 2008 22:48 UTC (Mon)
by drag (guest, #31333)
[Link] (4 responses)
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.
Posted Sep 23, 2008 1:16 UTC (Tue)
by dmarti (subscriber, #11625)
[Link]
Posted Sep 23, 2008 1:16 UTC (Tue)
by JoeBuck (subscriber, #2330)
[Link] (2 responses)
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?
Posted Sep 23, 2008 7:31 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Sep 25, 2008 14:59 UTC (Thu)
by dmarti (subscriber, #11625)
[Link]
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.
Posted Sep 23, 2008 3:11 UTC (Tue)
by arjan (subscriber, #36785)
[Link] (4 responses)
Posted Sep 25, 2008 15:13 UTC (Thu)
by dmarti (subscriber, #11625)
[Link] (3 responses)
Posted Sep 26, 2008 2:24 UTC (Fri)
by njs (subscriber, #40338)
[Link] (2 responses)
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
Posted Sep 26, 2008 15:05 UTC (Fri)
by dmarti (subscriber, #11625)
[Link] (1 responses)
(And you could always do the fsync in a separate thread or process, so the app is responsive again.)
Posted Sep 26, 2008 21:43 UTC (Fri)
by njs (subscriber, #40338)
[Link]
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...
Posted Sep 23, 2008 17:09 UTC (Tue)
by s0f4r (guest, #52284)
[Link]
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.
Posted Sep 23, 2008 0:36 UTC (Tue)
by csawtell (guest, #986)
[Link] (4 responses)
Any chance of doing that?
Posted Sep 23, 2008 1:14 UTC (Tue)
by dmarti (subscriber, #11625)
[Link]
Posted Sep 23, 2008 8:53 UTC (Tue)
by k3ninho (subscriber, #50375)
[Link] (2 responses)
K3n.
Posted Sep 23, 2008 10:05 UTC (Tue)
by rvfh (guest, #31018)
[Link] (1 responses)
Posted Sep 23, 2008 21:22 UTC (Tue)
by csawtell (guest, #986)
[Link]
Posted Sep 23, 2008 2:33 UTC (Tue)
by jreiser (subscriber, #11027)
[Link] (1 responses)
Posted Sep 23, 2008 17:10 UTC (Tue)
by s0f4r (guest, #52284)
[Link]
The video was shot about one week before the conference, not the evening before :)
Posted Sep 23, 2008 4:42 UTC (Tue)
by salinuxam (guest, #50554)
[Link]
Posted Sep 23, 2008 5:42 UTC (Tue)
by eru (subscriber, #2753)
[Link] (1 responses)
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.)
Posted Sep 25, 2008 7:58 UTC (Thu)
by cdamian (subscriber, #1271)
[Link]
Posted Sep 23, 2008 6:14 UTC (Tue)
by eru (subscriber, #2753)
[Link] (3 responses)
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...
Posted Sep 23, 2008 7:34 UTC (Tue)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Sep 23, 2008 17:12 UTC (Tue)
by s0f4r (guest, #52284)
[Link] (1 responses)
Posted Sep 23, 2008 20:10 UTC (Tue)
by nix (subscriber, #2304)
[Link]
(of course we still need /lib/cpp for the occasional non-X program that
Posted Sep 23, 2008 8:45 UTC (Tue)
by mjthayer (guest, #39183)
[Link] (6 responses)
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?
Posted Sep 23, 2008 9:53 UTC (Tue)
by etienne_lorrain@yahoo.fr (guest, #38022)
[Link] (1 responses)
Even if the only retribution the software writers ask for is a copyright line?
Posted Sep 23, 2008 10:04 UTC (Tue)
by mjthayer (guest, #39183)
[Link]
Posted Sep 23, 2008 13:26 UTC (Tue)
by Cato (guest, #7643)
[Link] (2 responses)
Posted Sep 23, 2008 13:31 UTC (Tue)
by mjthayer (guest, #39183)
[Link] (1 responses)
Posted Sep 24, 2008 8:57 UTC (Wed)
by maney (subscriber, #12630)
[Link]
Posted Sep 23, 2008 17:14 UTC (Tue)
by s0f4r (guest, #52284)
[Link]
Posted Sep 23, 2008 12:24 UTC (Tue)
by MisterIO (guest, #36192)
[Link] (2 responses)
Posted Sep 23, 2008 17:20 UTC (Tue)
by s0f4r (guest, #52284)
[Link] (1 responses)
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 :)
Posted Sep 23, 2008 22:12 UTC (Tue)
by MisterIO (guest, #36192)
[Link]
Posted Sep 23, 2008 13:00 UTC (Tue)
by jpmcc (guest, #2452)
[Link] (6 responses)
John
Posted Sep 23, 2008 13:39 UTC (Tue)
by etienne_lorrain@yahoo.fr (guest, #38022)
[Link] (2 responses)
Posted Sep 23, 2008 17:43 UTC (Tue)
by hmh (subscriber, #3838)
[Link] (1 responses)
lsof +L1 | grep lib
together with
lsof -n | grep 'path inode' | grep lib
will give you that info, for example.
Posted Oct 3, 2008 11:03 UTC (Fri)
by pabs (subscriber, #43278)
[Link]
apt-get install debian-goodies ; checkrestart -v
That gives you package names and init scripts to run.
Posted Sep 23, 2008 18:12 UTC (Tue)
by arjan (subscriber, #36785)
[Link] (2 responses)
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.
Posted Sep 25, 2008 16:18 UTC (Thu)
by kamil (guest, #3802)
[Link] (1 responses)
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...
Posted Sep 30, 2008 21:27 UTC (Tue)
by salimma (subscriber, #34460)
[Link]
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...
Posted Sep 24, 2008 17:58 UTC (Wed)
by xed (guest, #52285)
[Link]
Posted Sep 25, 2008 8:34 UTC (Thu)
by phillemann (guest, #49231)
[Link] (2 responses)
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.
Posted Sep 25, 2008 14:24 UTC (Thu)
by nix (subscriber, #2304)
[Link]
That's a *long* time to change video mode.
Posted Sep 25, 2008 14:56 UTC (Thu)
by arjan (subscriber, #36785)
[Link]
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.
Posted Sep 25, 2008 11:24 UTC (Thu)
by mlankhorst (subscriber, #52260)
[Link]
Posted Sep 26, 2008 0:41 UTC (Fri)
by Hawke (guest, #6978)
[Link] (3 responses)
Posted Sep 26, 2008 13:42 UTC (Fri)
by dmarti (subscriber, #11625)
[Link] (1 responses)
Posted Oct 3, 2008 13:32 UTC (Fri)
by ummmwhat (guest, #54087)
[Link]
Thanks in advance.
Best regards...
Posted Sep 30, 2008 16:37 UTC (Tue)
by syntropy (guest, #54409)
[Link]
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 …
Posted Oct 3, 2008 7:44 UTC (Fri)
by jordoex (guest, #54491)
[Link]
Posted Oct 3, 2008 12:48 UTC (Fri)
by reed (guest, #54499)
[Link]
Posted Oct 6, 2008 10:58 UTC (Mon)
by endecotp (guest, #36428)
[Link]
Posted Oct 6, 2008 18:32 UTC (Mon)
by gumby (guest, #54545)
[Link] (2 responses)
Why are computers so slow at starting, maybe it takes them a while to warm up and get those electrons flowing.
Posted Oct 6, 2008 20:46 UTC (Mon)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Oct 8, 2008 3:31 UTC (Wed)
by pgan (guest, #54573)
[Link]
Posted Oct 20, 2008 11:04 UTC (Mon)
by skeldoy (guest, #54795)
[Link] (1 responses)
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?
Posted Nov 5, 2008 21:10 UTC (Wed)
by tholme (guest, #54306)
[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
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
Video is available on youtube
Video is available on youtube
Video is available on youtube
Benefit of sReadAhead on SSD
Video is available on youtube
Now what about shutdown?
Don't miss the video that Arjan has posted on youtube.Now what about shutdown?
Val Henson did a related LWN piece on Crash-only software. You have to write crash recovery anyway, so why not "crash" every time?
Just crash.
Val Henson wrote an article about that for LWN: Link.
Now what about shutdown?
Now what about shutdown?
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.)
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.
Other fun features for "crashable" apps
Now what about shutdown?
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?
Now what about shutdown?
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.
When is "save" really "maybe save"?
When is "save" really "maybe save"?
Now what about shutdown?
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.LPC: Booting Linux in five seconds
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
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
He did.
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
No moss
Hat's off to tux
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.
SPLASH!
SPLASH!
The X Window System runs the C preprocessor and compiler on startup,
in order to build its keyboard mappings.
X11 and CC?
X11 and CC?
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 listsX11 and CC?
X11 and CC?
uses imake. Can't live without xpilot, now, can we. ;) )Splash screens and initramdisk
Splash screens and initramdisk
Even if the kernel is going to unsupported (tainted) mode loading a driver?
Anyways, it is a lost cause already.Splash screens and initramdisk
Splash screens and initramdisk
Splash screens and initramdisk
Hmmmm... Isn't that what Windows does, though without any very useful fallback when it fails?
Splash screens and initramdisk
Splash screens and initramdisk
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
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
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
from typing 'startx' through to the display stabilizing and .Xinitrc
beginning to be executed.LPC: Booting Linux in five seconds
Filesystem optimization?
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
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.
They are
Are the .config available
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. LPC: Booting Linux in five seconds
Kyuba.
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
message output
LinuxBIOS / CoreBoot
I can start my 1978 Ford Pinto in 4 seconds
I can start my 1978 Ford Pinto in 4 seconds
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
LPC: Booting Linux in five seconds
He got rid of the initrd and made som changes to the kernel. You can find them in his fastboot.git-tree
LPC: Booting Linux in five seconds


![[Fedora bootchart]](https://static.lwn.net/images/fastboot/fastboot-f1_sm.png)
![[Ubuntu bootchart]](https://static.lwn.net/images/fastboot/fastboot-f2_sm.png)
![[Asynchronous hardware
init]](https://static.lwn.net/images/fastboot/fastboot-f3_sm.png)
![[Parallel tasks]](https://static.lwn.net/images/fastboot/fastboot-f4_sm.png)
![[5 second boot]](https://static.lwn.net/images/fastboot/fastboot-f5_sm.png)