Linux Performance Tuning for the Faint of Heart
'Kernel profiling support' CONFIG_PROFILE :
This is used only by seasoned kernel hackers. You don't need this if you need to read this article...
'Selection (cut and paste for virtual consoles)' :
Self explanatory. If you want to be able to use your mouse in any of your VC's, then you would select YES. Note that this requires a separate selection program to work. Your mouse will be inactive without this program. This has nothing to do with X-windows.
The last section of the configuration process that needs insight has to do with sound card options. If you want sound card support, then you would definitely select YES. The confusing part are the next two questions; confusing because of the order they fall in.
Full driver? NO. I select NO because I want to configure my kernel to handle only my particular sound card. I don't want to enable drivers for cards I don't have. This simply wastes space.
Immediately following is: Disable? NO. It seemed strange to me that the driver question would come before a question about disabling the sound drivers altogether. Nonetheless, you should select NO, and answer the questions that follow accordingly, depending on what hardware you have.
That was the last part of the configuration process. All that remains is to make the system dependencies. After that, the actual kernel compile!
There isn't any confusing part about making the dependencies. All you do is type make depend (in the /usr/src/linux directory, which you should already be in); this sets up the system dependencies that all the files have. This allows make to intelligently recompile only the right files if you have to make changes to the source code.
After the system dependencies have been created, you are ready to compile the newly configured kernel. At this point, you should type make zImage to create a compressed kernel. This helps in the process of keeping your kernel small. Depending on the speed of your machine, the amount of memory you have, and how many things you are compiling into your kernel, your compile could take anywhere from around 15 minutes on a fast 486 or Pentium to several hours on a slow 386sx with 4MB of memory.
When the compiling process is complete, you will find a newly created kernel, zImage, in the /usr/src/linux directory. The process of installing the new kernel however is not yet complete. If you reboot right now, even though you have compiled a new kernel, you will still boot your old kernel. You still need to install the new kernel.
Before you install the new kernel, you should rename your old kernel, so that you can use it in the case of an emergency. In the / directory, there should be an image of your old kernel (zImage). Simply rename it to zImage.old using the mv command. This will be useful in the event that your new kernel will not boot up; you at least have a backup that still allows for a functional system.
Now, you must edit (if necessary) the LILO configuration file, so that it will accept your new kernel. It is most often found in the file /etc/lilo/config, but may be found as /etc/lilo.conf. Basically, editing the configuration file and running lilo tells the LILO which kernel to use upon bootup. The first image to be set up in the config file will be the default. By putting the new kernel image first, we will ensure that the new kernel boots by default; if we were to put the DOS entry first, DOS would boot by default. Here's an example:
boot = /dev/hda
#This is the path to the NEW kernel image to be bootedimage = /zImagelabel = linux
#This is the path to the OLD kernel image to be booted#if the other should fail to bootimage = /zImage.oldlabel = linux.old
#This is the path to the DOS operating systemother = /dev/hda1table = /dev/hdalabel = dos
Once you've edited the configuration file, copy or move the new kernel image to the / directory. Make sure that /zImage and /zImage.old are present before going any further. Next, you need to go back into the /etc/lilo directory and type ./lilo to run lilo. Alternately (if /etc/lilo doesn't exit), you may need to cd to /etc and run /sbin/lilo. In either case, this is the “installation” step which makes it possible for you to boot your new kernel.
You are now ready to boot your new kernel. To do this, type shutdown -r now.
If you have not installed your new kernel as the default kernel by making it the first entry in /etc/lilo/config, you will need to manually select your new kernel as you boot up. You activate the LILO menu by pressing <shift>, <control>, or <alt keys> as LILO is starting, or by pressing the <CapsLock> or <ScrollLock> key before LILO starts.
At the LILO prompt, make sure you type the label of the image, and not the filename of the image. If LILO can't find the image you ask for, it will tell you. Typing ? will give you a list of labels to choose from.
During the boot process, be sure to look at the information that relates the version of the kernel being booted, and the day that it was compiled (it's all on the same line). Mine looks like this:
Linux version 1.0.9 (root@HoMiEz.ShOpPiN.NeT) Thu Jul 14 22:45:16 1994
This particular line tells which version of the kernel is being booted, and the date and time that it was last compiled. The information shown here should coincide with the compile process you just recently completed. If there is an inconsistency, be sure to check your /etc/lilo/config file. Make sure that you put the proper label name for the particular table on the hard drive.
Once the new kernel is booted, you are free to hack away. Kernel compiling can be a confusing process. Some new administrators are intimidated by compiling a new kernel, but it is a prerequisite to running an optimized system. After a few kernel upgrades, you can become skilled in maintaining your system optimally. Then you can pass that knowledge to those who are as unsure as you once were. Remember, the more you know about your own system, the more optimized you become in using it.
Before you unpack the kernel source, it is a good idea first to backup you old kernel. You should do this, just for the moment, until you completely get the new kernel functioning properly. You can even shrink the size of the old kernel source by using tar and then compressing it. It is better to use both, as a double strength method:
cd /usr/srctar cvf linux-old.tar linuxgzip -9 linux-old.tar
The resulting file should be linux-old.tar.gz. After you've done this, it is safe to remove the old source directory by typing:
rm -rf linux
After you've done this, you can uncompress the new kernel. You must first move the new kernel source to /usr/src. Then type the following:
gunzip -c new-kernel-name.gz | tar xvof -
Once this process is complete, you are ready to move on. I'd also suggest keeping the new compressed kernel source in a backup directory. This way, if an error occurs in the process of upgrading and compiling your new kernel, you always have un-patched, “virgin” source to start over with. This eliminates the time it takes to download the kernel source again and also leaves you more time to concentrate on the task at hand.
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- RSS Feeds
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Validate an E-Mail Address with PHP, the Right Way
- New Products
- Readers' Choice Awards
- Ahh, the Koolaid.
5 hours 21 min ago
- git-annex assistant
11 hours 21 min ago
- direct cable connection
11 hours 43 min ago
- Agreed on AirDroid. With my
11 hours 54 min ago
- I just learned this
11 hours 58 min ago
12 hours 28 min ago
- not living upto the mobile revolution
15 hours 19 min ago
- Deceptive Advertising and
15 hours 55 min ago
- Let\'s declare that you have
15 hours 56 min ago
- Alterations in Contest Due
15 hours 57 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.