Improve (potentially halve) login time by using readahead
NOTE: This tip NO LONGER APPLIES to Ubuntu 9.10 and higher -- these releases use a new "sreadahead" subsystem that takes care of reprofiling automatically whenever the bootup sequence changes (and also monthly).
PREFACE:
It has been well-documented that Ubuntu's readahead system during boot significantly cuts down on boot time by reducing hard disk seeking via precaching commonly-used files during bootup. This feature, however, only lasts up to the GDM screen. The average modern PC should be able to boot Ubuntu from GRUB to the GDM screen in under 30 seconds -- roughly half of what it would be if readahead were to be turned off.
For me, I start a lot of things when I log into my GNOME session. My laptop
boots from GRUB to GDM in about 14 seconds, but from the moment I log in to a full desktop is nearly 40 seconds, most of the time the disk is seeking like crazy. This led me to wonder, is it possible to extend readahead's benefits to accelerate the login sequence?
RISK/KNOWLEDGE DISCLAIMER:
This guide asks you to use the command-line to issue some commands, and uses the readahead-list and readahead-watch applications to profile a bootup. Changes to the system are easily reversible and the worst negative impact would be a reduction in login speed (the irony!). Of course, since you will be doing some things with root access, failure to correctly type in some commands may lead to permanent damage to your software or data. These changes are unsupported by Ubuntu developers.
SYSTEM SPECS:
Ubuntu Gutsy on Core Duo 1.66GHz with 1GB RAM. Slow laptop 5400RPM drive. You probably shouldn't try this unless you have more than 512MB RAM.
System was rebooted cleanly and I inputted my login when all disk activity stopped. Then, I logged in and waited for all disk activity to stop again. This login time is what I aim to reduce.
On my particular system, with a highly customized GNOME session, this login time without optimization is: 40 seconds. A subsequent login (where everything would be cached, ideal boot speed with disk bottleneck removed) takes: 13 seconds. I will try to get as close to that as possible!
PART 1: Profile Login Sequence
First, we need to ask readahead to monitor a login sequence and make note of all the files read during this period. Advanced users may point out that during bootup, there is a GRUB argument "profile" that causes Ubuntu to optimize bootup. We will need to essentially manually replicate what this boot option does, but save the output to a different file.
First, let's store our readahead list into a ~/.readahead directory.
Now, log out, and press CTRL+ALT+F1 to log into a terminal. Start the profiler:
Code:
sudo readahead-watch -o ~/.readahead/gnome.root /
This will grind the disk for a while (up to a few minutes) then it will return you to a command prompt. The profiler is now in the background watching all actions. Now, without logging out, go to your GDM prompt (ALT+F8 ) and log in normally.
after you are fully logged in, press CTRL+ALT+F1 to go back to your terminal, then run:
Code:
sudo killall readahead-watch
sudo chown jdong:jdong ~/.readahead -R
Replace jdong:jdong with your user and group name. Now, we need to go prune this list a bit. Especially if you have large files on your desktop (like a 1GB AVI), the login sequence may touch it, causing readahead to think it should load the whole thing into memory! In a terminal, run:
Code:
cat ~/.readahead/gnome.root | xargs -i ls -lk {} | sort -rn -k +5 | less
This will display all the files readahead wants to cache, sorted by largest file first. The 5th column (before date) is the size of the file in KB. Make sure there's nothing glaringly large. If it's bigger than 10,000KB or so, it's probably not worth preloading. You can remove unwanted files from the preload list by opening ~/.readahead/gnome.root in your favorite editor, and deleting its line.
If you have home on a different partition as root, you should repeat Part 1 for each partition, replacing gnome.root with a different name, and replacing the mountpoint / with each interested mountpoint.
PART 2: Hooking this into the login sequence.
Next, we need to tell Ubuntu to do this readahead on every login. I am going to use /etc/X11/Xsession.d for this, but if you have another preferred way to execute things before everything loads, be my guest!
Create a file called /etc/X11/Xsession.d/00readahead and put this in it:
Code:
for list in ~/.readahead/*; do
readahead-list $list &
done
wait
Save the file. Now, you can reboot to try it out. You will notice the login
"hang" at the orange screen while the disk works without much grinding, then once that is done the bootup should soar as if it were a fully cached login. This brings my login session to around 30 seconds, a notable improvement.
PART 3: Hook into bootup sequence
Often times, we don't log in immediately when the prompt comes up. We might be getting a cup of coffee, or an entire lab might be turned on before students arrive. It makes sense to cache a login as a part of bootup. Open up /etc/rc.local in your favorite text editor, and before the exit 0 statement, add:
Code:
for list in /home/jdong/.readahead/*; do
readahead-list $list
done
Note you need to hard-code a particular user in there, and this time we don't background it. (We could, but there is not much motivation to)
Now, reboot, and wait for all disk activity to stop before logging in. This
time, I get a login speed of 19 seconds.
You might have two common questions at this point:
1. How much time does it take to call readahead again on files that have been cached once already? About 0.05 seconds to call readahead on the same list a second time
2. How much overhead does it add to bootup if the background readahead was still going, and you tried to log in? About 2 seconds on my setup
CONCLUSION:
In my case, applying this readahead hack lead to a 10-second improvement in login speed in the worst-case scenario, and a remarkable doubling in login speed when the system idles at the login prompt for a few seconds.
This is a pretty appreciable improvement and it would be nice if a nicer version of this hack can be added to Ubuntu. The basic idea should be fairly simple to adapt to an /etc/readahead/readahead.gnome file representative of the default system and hooked by an Xsession.d script.
Potential follow-ups?
Many more applications come to mind as taking a long time to load while the disk grinds (Firefox? Openoffice? Eclipse?). You can use a procedure very similar to this to write a "wrapper script" that first performs a readahead-list call on a list, then call the application with the original arguments. I'd be interested to hear of any improvements gained by that method.
Undoing This Tip
Remove, remove, remove! Delete the ~/.readahead directory, delete /etc/X11/Xsession.d/00readahead, and delete the line you added to /etc/rc.local
Re: Improve (potentially halve) login time by using readahead
Re: Improve (potentially halve) login time by using readahead
Re: Improve (potentially halve) login time by using readahead
WOW!
Great how-to. I only did the first 2 parts (since I auto login to my main user there's no wait before login -- should I go ahead and do part 3?) but hot damn my login is fast. Ubuntu already beat XP (about 1/5 the time) but now I'm up and running less than a minute after hitting the power button.
PS: When I did this, CTRL+ALT+F7 got me back into the wonderful world of X -- not CTRL+ALT+F8
This should DEFINITELY be a part of all future Ubuntu releases.
Re: Improve (potentially halve) login time by using readahead
Quote:
Originally Posted by
maharbA
WOW!
Great how-to. I only did the first 2 parts (since I auto login to my main user there's no wait before login -- should I go ahead and do part 3?) but hot damn my login is fast. Ubuntu already beat XP (about 1/5 the time) but now I'm up and running less than a minute after hitting the power button.
PS: When I did this, CTRL+ALT+F7 got me back into the wonderful world of X -- not CTRL+ALT+F8
This should DEFINITELY be a part of all future Ubuntu releases.
I am thrilled it worked miracles for you. There's a bunch of network-related operations in my login sequence (remember -- heavily customized) so the average user should see much BETTER improvements than what I listed.
If you auto-login, there is no reason to do part 3. That's more for people who find themselves booting up and having the computer wait for you to log in.
Re: Improve (potentially halve) login time by using readahead
Sweet. I'm assuming that the file
is just your output file, is that right?
I'm running Kubuntu, and I just want to make sure I don't need to change anything.
If my thinking is correct, I could either leave the filename alone, since it really doesn't matter, or change it to kde.root
and have the same impact, is that correct?
thanks,
jimbo
Re: Improve (potentially halve) login time by using readahead
gnome.root is just an arbitrary name, you can call it whatever you want. This procedure works with whatever login session you use.
Re: Improve (potentially halve) login time by using readahead
Thanks for this howto! It worked great for me! Before it took ~30 seconds to go from Login Screen (with no disk usage) to Desktop (with no disk usage). Now, it is very quick!
Re: Improve (potentially halve) login time by using readahead
i wish i could claim such results on my machine, but i think readahead kind of misbehaves here : it actually slows down things very much (i noticed very high disk activity, so i suspect there's something wrong with caching - may i add there's no big file to be cached, but there seems to be a lot of small files).
note that this does not seems specific to this trick, because last time i added "profile" to my kernel grub entry (in order to speed up next booting processes using readahead), my bootcharts jumped from 60-65 seconds, to somewhere near 200 seconds. Culprit was : readahead. it would generate high disk activity for about 140 seconds.
maybe my ubuntu installation is getting old and messy…
Re: Improve (potentially halve) login time by using readahead
Hmm, how much RAM do you have?
Also, have you used the last command in part 1 to check what sizes are the files Readahead wants to load? I suspect there's some sort of large ISO image or something that Readahead is thinking it should load into RAM, but it really shouldn't.