Googling for filesystem performance enhancements, you might come upon a suggestion for ext3 and ReiserFS, involving another mounting option: data=writeback. This option effectively undoes the advantage of those two filesystems by partially disabling their journaling. (Journaling is what ensures that your data won’t be lost, even after a system crash.) If you include data=writeback, you’ll gain an increase in speed at the cost of having old data show up after a crash. I don’t like this kind of risk, so I don’t use that option.
/dev/null) and timed the results both with and without the noatime option and found some small performance enhance-ments—every little bit helps.
Now, if you gotten this far, you’re ready for the big one:
enhancing your kernel.
Get an Optimal Kernel
All the tweaks we have done so far are just part of the job, and you even can get a bit more speed if you recompile your kernel and adjust it optimally for your specific hardware and needs. Note that even though compiling a full kernel isn’t the challenge it used to be (mainly you just have to make a few choices and key in some commands), there still is room for botching things up. Don’t try this unless you feel comfortable.
Most distributions usually provide a one-size-fits-all kernel compiled with the most generic options, which should work for everybody. Of course, this won’t necessarily fit your specific case. If your box has an Athlon XP CPU (as my laptop does), or many processors, or a certain graphics card, the generic kernel won’t take advantage of them. What to do? You can tweak some kernel options and recompile it for optimal performance.
Here, I pay specific attention to the options that enhance speed and responsiveness.
Compiling your kernel isn’t that difficult, but remember there’s a distinct probability of hosing your machine and turn-ing it into a paperweight. (Okay, that may be a bit of an exag-geration. 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/cpuinfoto see how many CPUs you have and their brands, and cat /proc/meminfofor 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 appro-priate 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 hun-dreds of options, although luckily, you will have to change only a few of them.
If graphical interfaces are more your style, change the last command to make xconfigfor a friendlier way of working (Figure 2).
The following are some of the options to change:
I Under General Setup, uncheck Cpuset support.
I 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
INDEPTH
Note:
The specific commands used in this article are appropriate for the OpenSUSE distribution, but do vary from one distribution to another. Check your documentation for the specific com-mands you will need before trying to recompile your kernel.
Listing 3. You will need information about your CPU and RAM before recompiling your kernel.
$ cat /proc/cpuinfo processor : 0
vendor_id : AuthenticAMD cpu family : 6
model : 8
model name : Mobile AMD Athlon(tm) XP 2200+
[...some lines snipped...]
$ cat /proc/meminfo MemTotal: 483488 kB MemFree: 11560 kB Buffers: 19888 kB Cached: 323408 kB SwapCached: 2768 kB Active: 166432 kB Inactive: 230396 kB [...more lines snipped...]
Listing 4. Do a dry run to ensure that you have everything you need for compiling the kernel.
cd /usr/src/linux make clean make
make modules_install make install
w w w. l i n u x j o u r n a l . c o m m a rch 2 008 | 93 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 (stand-ing 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 num-ber of CPUs, enter the correct number. (All this data comes from doing cat /proc/cpuinfo, as discussed previously.)
I Under Block Layer, uncheck every-thing, unless you have disks larger than 2Tb.
I 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 Figure 1. make menuconfigprovides a console-like way to select kernel options.
Figure 2. make xconfigproduces a friendlier, graphical way to choose kernel options.