Slashdot Mirror
How To Speed Up Linux Booting
An anonymous reader writes "A common complaint about Linux is the amount of time the operating system takes to start. Like Linux itself, there are plenty of options and lots of flexibility for boot-time optimization. From dependency-based solutions like initng to event-based solutions like upstart, there's an optimization solution that should fit your needs. Using the bootchart package, you can dig in further to understand where your system is spending its boot time to optimize even more."
My Linux setup is so optimised that this first post is actually made before opening Firefox and typing slashdot.org.
Ha!
I thought one of the arguments for linux was that you didn't need to reboot - like you do with Windows. So the boot time should not matter :-)
Any sufficiently advanced bug is indistinguishable from a feature.
in /etc/conf.d/rc:
rc_parallel_startup="yes"
(actually that should be in caps, but the lameness filter doesn't like it)
Most bootscripts are very generic in that they will try to load all sorts of RAID drivers, various services that are not needed, special fonts, etc.. I've gone in on my computers and wrote a very simple, quick, and to-the-point bootscript (easy to do with a little BASH knowledge), and my system boots up remarkedly fast. Granted, my bootscript isn't very portable, but one of the benefits of Linux is the ability to customize it.
Another trick is to prelink files and let KDE (if that is what you use) know about it. Even the startkde script can be long and drawn out, so trimming the fat and only including what's needed on your system can make a big difference. I've shaved over 13 seconds off a boot sequence by writing a minimum bootscript for my hardware, and that was using a relatively fast distro to start with.
-Mike
There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy.
When I went out to take advantage of the article's suggestions, I found that, according to this thread in the Ubuntu Forums that Ubuntu 6.10 already uses Upstart.
I did used the "profile" command in my bootup once, after reading about it in another article recently. So I guess my Ubuntu is booting about as fast as it can (unless I have useless processes starting up. I'm still trying to figure that out--I'm a noobie).
The world doesn't end just near your nose. You may have a laptop and you may be happy with "hibernating" it, but many of us need to power off PCs. An office PC I power on every day, my home's PC I power on and off when I get and leave home.
And it's your comment the one that is insulting. You insult lots of experienced Linux users who do care about their machines booting several times slower than an XP pc.
And why is that? Because Linux boots up with a slow and serialized process, in which the whole system (with hyperthreading, gigs of ram, dual core, etc.) sits idel waiting for a single stupid syslog daemon to start, or worse: waiting for a DHCP client to get an IP address!
init 11 - for when you need that edge.
Comparing fresh Linux and XP and OS X installs, Linux is by far the slowest to boot. If your school's XP installs boot slowly, they are probably doing a lot of work like transferring lots of data over a slow network connection.
Or maybe he's just counting the time until the computer is actually usable. With Linux once the computer is booted, and you see the desktop, it's ready to use. With windows, it takes another 20 seconds (at least) after the desktop appears for it to actually become usable.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
That ARM board stores the entire operating system in flash. It uses busybox and pretty much nothing else, to get a shell up that fast. It doesn't have to wait for any hard drives or peripherals to initalize. LinuxBIOS can do similar things, but only on some machines. TFA is all about getting services to start quickly. Turning off everything is not an acceptable alternative.
Denying the problem doesn't make it go away, really. All the hibernation and sleep modes in the world don't change the fact that Linux boot times are much longer than, say, Windows XP's.
I'm sorry, but I run both Windows and Linux on my Dell Inspiron 6000 laptop, and booting Linux takes much, much longer. We're talking 2-3x longer, in fact.
Yeah, that's nice and all, assuming the power management actually works correctly.
Which, for many laptops, it doesn't. For instance, some time ago I finally managed to get hibernation mode to work (after a lot of fiddling), but it was still experimental at the time (ca. half a year ago) and would crash on resume sometimes. Not good when you have some important applications still running.
Now I'm running a different distribution (FC5) and it hangs after resuming from "normal" sleep mode (which is activated when I close the lid).
So yes, boot time is quite relevant for me, thank you very much, and saying this is FUD is
Or perhaps they are people who get tired of having to spend 2 weekends to get some stupid features, such as sleep mode and hibernation, to work correctly. Which then promptly breaks, of course, on the next kernel upgrade (which, in my case, was needed to get wireless to work).
This is also why I won't bother with trying to speed up the boot-time of my laptop, I'm waiting for some decent distro which does it for me!
Every expression is true, for a given value of 'true'
Anybody else appalled by the amount of people saying "just don't turn it off"?. I know I am. It's shocking for various reasons:
If you leave your computer on 24/7 just for convenience, then perhaps you ought to consider the possibility that you are a spoilt rich selfish pussy and not the infallible sysadmin you undoubtedly believe yourself to be.
All in all, playing with parallelized OS startup is very nice but the real problem lies elsewhere...
In my experience (data center, 350+ Intel-based servers, Linux + Windows plus a bunch of SPARC Solaris boxes), the OS boot time is negligible compared to the time needed for hardware initialization:
- BIOS startup
- Memory check
- Remote Console init (DRAC/XSCF etc.)
- RAID Controller(s) init, disk spinup
- RAID Consistency Check, volume initialization
- Start Boot Sequence
Especially the disk subsystems cause large delays - most time is spent waiting for the GRUB screen.
Parallelizing the hardware initialization is where we could make some significant progress.
-- Gxis! Ed.
Because I only reboot my computers when I have to, like when I get an update to the kernel. The rest of the time, they just waste electricity and CPU cycles, and generate excess heat my A/C unit has to deal with! :-)
No matter where you go... there you are.
Ever since Ubuntu Edgy much of the low hanging fruit in speeding up the Ubuntu boot has already been taken. Looking at the bootcharts for my system since then shows remarkably little time when the CPU is idle once the base kernel has finished loading. This means that running anything more in parallel simply won't net me anything (in fact scheduler overhead and disk thrashing may in theory make things slower).
For example, there is an improvement in the time it takes for the clock to appear from "Ubuntu Dapper Flight 3 Default kernel" to "Ubuntu Feisty Herd 5 generic kernel". The Ubuntu folks worked hard to try an eliminate sleeps from their initscripts and when a sleep was unavoidable they would run other parts of the startup process in parallel. They also made changes to Xorg to prevent it (re)reading so much stuff on launch. There was also the introduction of the readahead script which tries to arrange for as much of the boot time reading to be done in one big chunk. Throughput is higher when the disk is only reading and can utilise it's readahead. An attempt is also made to try and request files in the order in which they are laid out on disk (to minimise disk seeks which hurt performance). In Feisty a move was made to using dash instead of bash for scripts because it was smaller and executes scripts faster.
The only things that seem to win me any gain over the default Ubuntu Feisty install are turning off initscripts for services I absolutely won't use (e.g. ipv4 autoconfig via avahi) and reducing the number of restricted binary driver modules being probed (I have long noticed that the only benefit that recompiling the kernel gives to boot speed is that you can simply leave out features not on your computer making the initial kernel startup where it probes for things you might not have (like which software RAID is faster) a shade faster). It is also worth noting that Ubuntu starts X quite early and continues loading services afterwards which means the gain from disabling one of these "after X" services (like CUPS) isn't so noticeable (but might mean your desktop actually starts responding to clicks a bit sooner).
Profiling the boot to try and improve the readahead takes a long time to run - the profile run seems to take three times as long as a regular boot. It could be argued that you will never gain back the extra time you waited on the profile run...
I suspect reducing the boot further will start to need more complicated procedures, perhaps reordering modprobe.conf and reducing the amount of needless reading of files. Eventually you end up having to do the same tricks as Windows/OSX - e.g. working out where the fastest part of the disk is and copying every file needed to boot there, bringing up the network cardafter the desktop has started, periodically defraging bits of the disk, prelinking...