Results 1 to 10 of 152

Thread: Improve (potentially halve) login time by using readahead

Threaded View

  1. #1
    Join Date
    Oct 2004
    Location
    Cupertino, CA
    Beans
    5,092
    Distro
    Ubuntu 10.04 Lucid Lynx

    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.

    Code:
    mkdir ~/.readahead
    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
    Last edited by jdong; November 2nd, 2009 at 03:40 PM.
    Quote Originally Posted by tuxradar
    Linux's audio architecture is more like the layers of the Earth's crust than the network model, with lower levels occasionally erupting on to the surface, causing confusion and distress, and upper layers moving to displace the underlying technology that was originally hidden

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •