Maximize Desktop Speed

Are you a speed junkie who wants the fastest, most responsive machine? Try these changes and get even more speed out of your Linux box.

Compiling your kernel isn't that difficult, but remember there's a distinct probability of hosing your machine and turning it into a paperweight. (Okay, that may be a bit of an exaggeration. In the worst case, you simply would have to re-install Linux, and you wouldn't lose your data.) In my case, I used the YaST administration tool and installed two kernels, so I could choose either of them at boot time, and if I destroyed one, I could reboot with the other one, re-install the broken kernel and keep trying.

You need some specific packages to do this: kernel-source (the source files for the actual kernel), gcc (the compiler), ncurses (for the menus) and bzip2 (used internally to create boot images). You also need to know a bit about your hardware. Use cat /proc/cpuinfo to see how many CPUs you have and their brands, and cat /proc/meminfo for RAM information (Listing 3).

Start with a dry run and recompile the kernel without any changes, just to see if everything is set up okay. Working as root, do what's shown in Listing 4.

The make processes will run for a while, and although they might produce some warnings, there shouldn't be any errors. If everything still is running okay after you reboot, it means you can start experimenting; you already did a kernel build. (If things did go seriously wrong, reboot with the other kernel, re-install the thrashed kernel, fix the problem, and try a dry run again.)

Tweaking the kernel is simply a matter of choosing the appropriate options from a (large) menu. As root, do the following:

cd /usr/src/linux
make clean
make menuconfig

and you will see a screen (Figure 1) with a menu full of hundreds of options, although luckily, you will have to change only a few of them.

Figure 1. make menuconfig provides a console-like way to select kernel options.

If graphical interfaces are more your style, change the last command to make xconfig for a friendlier way of working (Figure 2).

Figure 2. make xconfig produces a friendlier, graphical way to choose kernel options.

The following are some of the options to change:

  • Under General Setup, uncheck Cpuset support.

  • Under Processor Type and Features, check Tickless System and High Resolution Timer Support. Select the right CPU type under Processor Family, so the compiled kernel code will be optimized for it, and uncheck Generic x86 Support, which is needed only for generic kernels. Choose the amount of RAM you have under High Memory Support. Check Preempt the Big Kernel Lock, and under Preemption Model, choose Preemptible Kernel (Low-Latency Desktop). Note that for a server machine, you should select the No forced preemption option. Under Timer Frequency, choose 1000 (standing for 1000H). Finally, if you have a machine with only one CPU, uncheck Symmetric multi-processing support. If you have two or more CPUs, check that box, and under Maximum number of CPUs, enter the correct number. (All this data comes from doing cat /proc/cpuinfo, as discussed previously.)

  • Under Block Layer, uncheck everything, unless you have disks larger than 2Tb.

  • Under Kernel Hacking, uncheck Kernel Debugging, Collect kernel timer statistics, Debug preemptible kernel and Write protect kernel read-only data structures.

After you are done selecting options, exit the configuration program (say “yes” to save the new kernel configuration) and then do the following:

make modules_install
make install

Watch for unexpected error messages; there should be none. You will need to wait, as when you did with the dry run. On my laptop, the complete process requires more than 30 minutes. If you get an error message, either go back to the menu to try to fix whatever was wrong, or reboot with your backup kernel, re-install the broken kernel, and try again. If everything is okay, simply reboot, and try out your new kernel.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

How to get rid of fonts?

Roland's picture

OK, so 'xfontsel' shows I have over 10K fonts. Many of the families are clearly foreign languages, that came with install. How do I get rid of some of them? 'apropos font' was no help, and 'adept' indicated I didn't have any font packages installed. I use Kubuntu. 'man apt-get' didn't give me a clue about finding font packages. Suggestions? Thanks.

Wrong information about prelink

sspr's picture

The section about prelink is incorrectly stating that...

Using prelink in this way obviously requires more disk space (for there will be a copy of every prelinked library within each executable file), but with the current large disks, this won't even be noticed.

This is complete rubbish ! The author is clearly confusing rewriting the relocation tables with hard-wiring the libraries in executables. The scheme set up by the author would turn all binaries into static linked programs. Nothing is less true ! As a simple peek at the man page (or even Wikipedia) reveals, only the relocation tables are rewritten such that when a library is loaded into memory, it's symbols sits at the right spot in the virtual memory, such that the calculation of the symbol locations no longer needs to be done, but is exactly there where the program expects them.

So prelinking does not use a single byte (apart from the lightweight checksum mechanism) more disk space.

Another blatant fault:

Include the -m option so prelink will try to conserve memory, if you have many libraries in your system (highly likely) and not a very large memory.

This has *nothing* to do with your actual memory, but with the 4GB virtual address space limit on 32bit systems ! It just means that, _if_ each library was used in a single program (and that's what prelink allows without the -m option), you'd exceed the virtual address space limit. The solution is to see which libraries are mutually exclusive linked and let them overlap in virtual memory, as they'll never occur at the same time in the same process.

This article is also quite mediocre in the section about compiling a kernel, you're supposed to know how many RAM your system has. Wrong again. It's perfectly safe/performant to turn on "High Memory Support (4GB)", even if you only got 1GB. And the instructions for compiling a kernel are of the lesser quality I've seen around. You, a daring non-kernel hacking user, should nowadays only install a kernel through your packaging system (like make-kpkg for Debian/Ubuntu) and not using the good old 'make' command, which might as well overwrite your current kernel image and leave your system in an unbootable state (for example, when initrd support has been omitted and your filesystem drivers are compiled as modules.)

This article had good intentions, but the proof reading (if any) clearly missed some faults.