Friday, April 16, 2010

Gentoo Netbook: Tweaking Performance, Part 1

Below is some information on speeding up performance for a Gentoo netbook system. This is all just for testing and fun, and has worked well for me... the usual disclaimers apply.

I've been running gentoo on my netbook (eeepc 1000HA) for quite a while now and it works great, especially using a minimal environment. Recently though I got the urge to find ways I could push the performance on it a bit further, and I've been rather pleased with the results.

This First Post will be purely about portage, and following shortly I will post about ways to boost the system's performance in general.

Portage:
The largest performance hit gentoo faces on a netbook is in the use of portage, lower end processing power and a slow hard drive can make compiling large numbers of packages a painful process. Here are a few methods to speed things up a bit.

Enable Parallel Fetching.
This tells portage that it should continue to download all of the required packages for an emerge even while it begins compiling those who's downloads have finished. This means that by the time the first package has finished compiling, the next one is already downloaded and ready to go. This will save a little chunk of time for each package involved, and that can really add up if you emerge is > 100 packages.

To do this, just add "parallel-fetching" to your make.conf features.

...
FEATURES="userfetch parallel-fetch"
...

Enable tmpfs for portage temp files.
When emerging packages all of the temporary files are written to disk, then read and executed as needed. This is a massive performance drop for any machine and in particular for machines with slower hard-drives. By default however, gentoo has an available tmpfs ramdisk that is available for our use at /dev/shm, and by keeping all of portage's temp work in ram we can speed things up quite a bit.

First add the following to your make.conf:

...
PORTAGE_TMPFS="/dev/shm"
PORTAGE_TMPDIR="/dev/shm"
BUILD_PREFIX="/dev/shm"
...

Next we need to allow execution from the ramdisk so we have to alter fstab and remove the noexec option. This is an exchange of security for performance, but this being a netbook and not a critical server, it's a reasonable trade off.

after removing the noexec option, the shm line in fstab should look like this:

shm   /dev/shm  tmpfs  nodev,nosuid  0 0

Then unmount and remount shm

#umount shm
#mount shm

more info on /dev/shm -> gentoo-wiki: Gentoo:/dev/shm

WARNING: some very large programs take more space to compile than most systems can handle in memory. An example of this is openoffice, which requres ~6GB of space during the emerge process. If you run into failed compiles due to lack of space, emerge their binary equivilents if they have them or temporarily comment out the shm section of your make.conf. So far I have only had this happen with openoffice (laptop with 4GB ram allocated 2GB dynamic to the shm device, which oo used up before it was even finished unpacking).


CCACHE
Any time you change a use-flag or an ebuild is updated, you will have to recompile that package. CCACHE helps to save some time by keeping a store of precompiled data and then comparing that data to what is required for the new build. The result is that only the parts of the ebuild that are changed need to be recompiled, the rest is provided by ccache. For the best results, ccache should be one of the first packages installed on a system so that it's cache can begin getting built with every new package.

Only two things need to be done to get CCACHE running:

#emerge ccache

and then add the following to your make.conf:

...
FEATURES="ccache userfetch parallel-fetch"
CCACHE_DIR="/var/tmp/ccache"
CCACHE_SIZE="4G"
...

No comments:

Post a Comment