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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide