Speeding up Portage and Kernel Compiling
Ever get annoyed by Gentoo’s forever-lasting compiling? Here is few tricks I found that really helps when surfing through gentoo-wiki.com.
To speed up Portage compiling, the trick here is to mount a ramdisk at Portage temp compile directory. Everything in that directory will be placed onto RAM instead of going to disk, therefore greatly improves speed.
This is the time needed to compile xorg-server.
Before:
real 9m18.899s
user 9m49.958s
sys 4m18.195s
After:
real 6m48.731s
user 5m9.471s
sys 4m6.079s
Impressive eh? 😉 Its a 33% speed up. Since everything is placed in RAM, when compiling very large package (namely openoffice) you might get this message.
IOError: [Errno 28] No space left on device
It means we have ran out of space for ramdisk. Unmount the ramdisk and proceed with emerge.
gentoo ~ # umount /var/tmp/portage/ gentoo ~ # emerge something Calculating dependencies - ... gentoo ~ # mount /var/tmp/portage/
Next, we can speed up kernel compiling by using ccache. Since most of the time kernel is compiled with minor changes, ccache would speed up the process dramatically by “re-using” files that are already compiled. Its quite troublesome to make CC=”ccache gcc” -j3 everytime you want to compile the kernel, we can write up a script that simplifies the process.
File: /sbin/compile-kernel cd /usr/src/linux mount /boot make clean make CC="ccache gcc" -j3 && \ # -jN for parallel compiling (follow N = number of core + 1) make modules_install && \ make install && \ # this will install kernel to default /boot/vmlinuz symlink module-rebuild rebuild && \ # / You might want to comment out these two lines if update-modules # \ you dont have module-rebuild installed. make clean umount /boot cd $OLDPWD
As root, chmod u+x /sbin/compile-kernel to make it executable. Edit the script if necessary. To (re)compile kernel, just issue compile-kernel to do so.
Enjoy the blazing fast compiling. 🙂
Further reading:
Using ccache
Heyho,
well, take a look at the german
http://de.gentoo-wiki.com/wiki/Emerge_beschleunigen#Hinweise
The author claims that the kernel already highly buffers hdd access, so tmpfs would just reduce IO waiting time for hdd syncs. But therefore, he continues, is the -jN flag for the make command: you usually start more gcc instances at a time than you have CPUs in your computer, so one process can continue compiling while another might waight for the HDD.
Summing up, I have no idea whether tmpfs is useful or not. I think I’ll try it out on myself, since it’s quite easy to set up. Furthermore tmpfs has been improved over the last years, nowadays there’s an extensible tmpfs that will need only as many size in RAM as it actually contains. That sounds really worth a try.