The /boot Partition
The Linux kernel is stored in the partition with the /boot directory. New kernels must also be transferred to this directory. By default, RHEL configures a partition of about 100MB for this directory. This provides enough room for your current kernel plus several additional upgraded kernels.
The /proc Filesystem
The /proc directory is based on a virtual filesystem; in other words, it does not include any files that are stored on the hard drive. But it is a window into what the kernel sees of your computer. It’s a good idea to study the files and directories in /proc, as it can help you diagnose a wide range of problems.
Example 1. A Red Hat Enterprise Linux /proc directory
$ \ls /proc/
1 24 3120 3357 3640 crypto keys swaps
10 2415 3124 3388 3643 devices key-users sys
13871 2438 3147 3409 3655 diskstats kmsg sysrq-trigger
14238 259 3155 3445 3657 dma loadavg sysvipc
15843 262 3187 3446 3667 driver locks tty
17 292 3206 3457 4 execdomains mdstat uptime
18 2921 3222 3458 5 fb meminfo version
18263 2964 3248 3534 6 filesystems misc vmcore
18266 2966 3253 3539 7 fs modules vmstat
18267 2989 326 3543 85 ide mounts xen
18303 2993 3279 3546 86 interrupts net zoneinfo
19031 3 3291 3547 9 iomem partitions
196 3025 3305 3557 buddyinfo ioports schedstat
2 3054 3326 3558 bus irq self
22 3090 3334 3559 cmdline kallsyms slabinfo
233 3109 3345 3638 cpuinfo kcore stat
The numbered items are based on process IDs. For example, the process ID of init is 1. The files in this directory include the memory segments that make up the active process. The contents of each of these files include the active memory for that process.
The other items in the listing are files and directories that correspond to configuration information for components such as DMA channels or whole subsystems such as memory information.
Take a look at some of these files. For example, the /proc/meminfo file provides excellent information as to the state of memory on the local computer, as shown in Example 2. It can help you determine whether RHEL is having trouble detecting all of the memory on your computer.
Example 2. Detected memory information
$ \cat /proc/meminfo
MemTotal: 1048752 kB
MemFree: 46908 kB
Buffers: 160712 kB
Cached: 735564 kB
SwapCached: 0 kB
Active: 438248 kB
Inactive: 494976 kB
HighTotal: 311304 kB
HighFree: 14696 kB
LowTotal: 737448 kB
LowFree: 32212 kB
SwapTotal: 2031608 kB
SwapFree: 2031608 kB
Dirty: 48 kB
Writeback: 0 kB
AnonPages: 36800 kB
Mapped: 21612 kB
Slab: 43268 kB
PageTables: 2076 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 2555984 kB
Committed_AS: 113892 kB
VmallocTotal: 114680 kB
VmallocUsed: 4624 kB
VmallocChunk: 109876 kB
It can also help you measure the current memory state of your system. For example, if your system is overloaded, you’ll probably find very little free swap space. The HugePages settings are associated with over 4GB of RAM.
Now you can examine how Linux look at your CPU in the /proc/cpuinfo file, as shown in Example 3. In this particular case, the CPU family information is important; the CPU family value of 6 in this example corresponds to a 686 CPU. If you have a dual-core CPU (and both cores are detected), you will see two entries, even if you have only one physical CPU.
Example 3. Detected CPU information
$ \cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz
stepping : 11
cpu MHz : 2327.504
cache size : 4096 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc up pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips : 5820.56
Many programs are available that simply look at the information stored in /proc and interpret it in a more readable format. The top utility is a perfect example. It reads the process table, queries RAM and swap usage and the level of CPU use, and presents it all on one screen.
IP Forwarding
More importantly, there are kernel variables that can be altered to change the way the kernel behaves while it’s running. Sometimes it’s appropriate to configure a Linux as a router between networks. By default, it does not forward TCP/IP information. You can confirm this with the following command:
# cat /proc/sys/net/ipv4/ip_forward
0
If your computer has two or more network cards, you may want to activate IP forwarding with the following command:
# echo 1 >> /proc/sys/net/ipv4/ip_forward
# cat /proc/sys/net/ipv4/ip_forward
1
Naturally, you will want to make sure the setting is confirmed the next time you boot by activating the net.ipv4.ip_forward directive in the /etc/sysctl.conf file.
Saturday, February 28, 2009
Saturday, February 21, 2009
Kernel Services, Part 2
Best Practices
You should compile your kernel with only the elements you need. The more that is left out, the faster the whole system will run. For example, if there is no sound card, sound card support can be removed from the kernel. By removing unneeded devices, you will:
Generally, it is a good idea to have device drivers compiled as modules for any equipment that you may add in the near future. For example, if you may use your Linux computer as a router, you will need a second network card, and you can add support for that card to your kernel. For example, if you have a 3Com 3c595 network card installed but you also have some 3Com 3c905 cards in storage, it may be a good idea to include the 3c905 module. That way, you can simply swap in the new card and let the module load, causing minimum downtime.
Modules are kernel extensions. They are not compiled directly into the kernel but can be plugged in and removed as needed. When configured as a module, a hardware failure such as that of a network card will not cause the whole system to fail.
Kernel Concepts
You will need to understand some basic kernel concepts before you can compile your own kernel. Kernels can be organized as one big unit or as a lot of interconnected pieces. Kernels are called up by boot loaders when you start your system.
Monolithic Versus Modular
A monolithic kernel is a kernel in which all the device modules are built directly into the kernel. Modular kernels have many of their devices built as separate loadable modules. Monolithic kernels can communicate with devices faster, since the kernels can talk to the hardware only indirectly through a module table. Unfortunately, the typical monolithic kernel is huge, which reduces available RAM. In addition, some systems just can’t boot a kernel that’s too large.
Linux once had problems loading modular kernels for some hardware. What a monolithic kernel, the drivers are already there and are often more appropriate for certain components such as embedded hardware.
A modular kernel has greater flexibility. You can compile almost all drivers as modules, and then each module can be inserted into the kernel whenever you need it. Modules keep the initial kernel size low, which decreases the boot time and improves overall performance. If Linux has trouble loading a kernel module, you can use the modprobe or insmod command to load modules as needed, and add those options to the /etc/modprobe.conf file.
Updating the Kernel
Updating the kernel is not as difficult as it looks. You should never overwrite or upgrade an existing kernel, as mistakes happen. New kernels are handled by installing the newly built kernel in /boot and then adding another boot option to your boot loader configuration file (/boot/grub/grub.conf) for the new kernel.
If you install the new directly from a Red Hat configured RPM, it updates the boot loader automatically.
If you do make a drastic mistake and the kernel does not boot, you can simply reboot the system and select the old kernel from the GRUB menu. You should also save existing kernel configuration files so that you have a template for newer kernels. This is discussed in more detail later in future posts.
Other RHEL Kernels
There are a number of different kernels included with the RHEL installation files. You can and should install the kernel best suited to your system. Available RHEL 5 kernels are briefly discussed below. For the real versionnum, run the uname -r command. To verify your arch, or architecture (such as i686), run the uname -m command. As described in the table, there are different versions of kernel devel, kernel PAE, kernel xen, and kernel headers packages for each supported architecture.
The list provides just a short list of kernel packages available for RHEL 5. It does not include Xen-related kernels. For more information on RHEL kernels available for multi CPU or higher-end CPUs, refer to the RHEL documentation available online from www.redhat.com/docs/manuals/enterprise/.
You should compile your kernel with only the elements you need. The more that is left out, the faster the whole system will run. For example, if there is no sound card, sound card support can be removed from the kernel. By removing unneeded devices, you will:
- Decrease the size of the kernel.
- Provide a modest increase in speed for the devices that are present.
- Make more hardware resources available for other hardware such as network cards, disk controllers, and so on.
- Reduce the risk of hardware limits, such as those that may be based on the size of the compressed kernel.
Generally, it is a good idea to have device drivers compiled as modules for any equipment that you may add in the near future. For example, if you may use your Linux computer as a router, you will need a second network card, and you can add support for that card to your kernel. For example, if you have a 3Com 3c595 network card installed but you also have some 3Com 3c905 cards in storage, it may be a good idea to include the 3c905 module. That way, you can simply swap in the new card and let the module load, causing minimum downtime.
Modules are kernel extensions. They are not compiled directly into the kernel but can be plugged in and removed as needed. When configured as a module, a hardware failure such as that of a network card will not cause the whole system to fail.
Kernel Concepts
You will need to understand some basic kernel concepts before you can compile your own kernel. Kernels can be organized as one big unit or as a lot of interconnected pieces. Kernels are called up by boot loaders when you start your system.
Monolithic Versus Modular
A monolithic kernel is a kernel in which all the device modules are built directly into the kernel. Modular kernels have many of their devices built as separate loadable modules. Monolithic kernels can communicate with devices faster, since the kernels can talk to the hardware only indirectly through a module table. Unfortunately, the typical monolithic kernel is huge, which reduces available RAM. In addition, some systems just can’t boot a kernel that’s too large.
Linux once had problems loading modular kernels for some hardware. What a monolithic kernel, the drivers are already there and are often more appropriate for certain components such as embedded hardware.
A modular kernel has greater flexibility. You can compile almost all drivers as modules, and then each module can be inserted into the kernel whenever you need it. Modules keep the initial kernel size low, which decreases the boot time and improves overall performance. If Linux has trouble loading a kernel module, you can use the modprobe or insmod command to load modules as needed, and add those options to the /etc/modprobe.conf file.
Updating the Kernel
Updating the kernel is not as difficult as it looks. You should never overwrite or upgrade an existing kernel, as mistakes happen. New kernels are handled by installing the newly built kernel in /boot and then adding another boot option to your boot loader configuration file (/boot/grub/grub.conf) for the new kernel.
If you install the new directly from a Red Hat configured RPM, it updates the boot loader automatically.
If you do make a drastic mistake and the kernel does not boot, you can simply reboot the system and select the old kernel from the GRUB menu. You should also save existing kernel configuration files so that you have a template for newer kernels. This is discussed in more detail later in future posts.
Other RHEL Kernels
There are a number of different kernels included with the RHEL installation files. You can and should install the kernel best suited to your system. Available RHEL 5 kernels are briefly discussed below. For the real versionnum, run the uname -r command. To verify your arch, or architecture (such as i686), run the uname -m command. As described in the table, there are different versions of kernel devel, kernel PAE, kernel xen, and kernel headers packages for each supported architecture.
- kernel-versionnum.i686 - Designed for PCs with a single Intel/AMD CPU; also works with dual-core systems.
- kernel-versionnum.ia64 - Designed for Itanium2 systems.
- kernel-devel-versionnum - Installs drivers and other information to help compile third-party drivers.
- kernel-PAE-versionnum - If you have more than 4GB of RAM, install the PAE kernel associated with your CPU architecture.
- kernel-PAE-devel-versionnum - If you have more than 4GB of RAM, install the PAE kernel associated with your CPU architecture.
- kernel-headers-versionnum - Includes kernel headers; often sufficient for drivers.
- kernel-versionnum.src.rpm - Includes the source code for the RHEL kernel.
The list provides just a short list of kernel packages available for RHEL 5. It does not include Xen-related kernels. For more information on RHEL kernels available for multi CPU or higher-end CPUs, refer to the RHEL documentation available online from www.redhat.com/docs/manuals/enterprise/.
Sunday, February 15, 2009
Kernel Services, Part 1
I'm starting a new post on Kernel Services, in which you will learn how to upgrade standard kernels as well as configure, compile, and install your own custom kernels. You will see several different ways to customize and optimize your kernel configuration for size and functionality. Finally, you will examine recommended techniques for configuring and installing the kernel.
You will also discover how to manage and modify special partitions associated with RAID arrays and LVM filesystems. While it’s most efficient to configure these partitions during the installation process, you may have to modify them during your exam.
In several places in this Kernel Services, I embed a command such as `uname -r` in the name of a directory or file. This command substitutes itself in the name of directory or file. If unsure, run it in your own system.
The Basics of the Kernel
The kernel is the heart of the operating system. It manages communication with hardware, decides which processes to run, and provides each process with an isolated, virtual address space in which to run. The kernel is what the GRUB boot loader loads into memory. The kernel loads device driver modules. It also allocates hardware resources such as IRQ ports, I/O addresses, and DMA channels. A recompiled kernel can lead to:
Xen is based on a specially customized Linux kernel for virtual machines. The files associated with the Xen-based kernel are different from regular kernels.
In the Kernel Services, Part 2 we will discuss Best Practices and Kernel Concepts.
You will also discover how to manage and modify special partitions associated with RAID arrays and LVM filesystems. While it’s most efficient to configure these partitions during the installation process, you may have to modify them during your exam.
In several places in this Kernel Services, I embed a command such as `uname -r` in the name of a directory or file. This command substitutes itself in the name of directory or file. If unsure, run it in your own system.
The Basics of the Kernel
The kernel is the heart of the operating system. It manages communication with hardware, decides which processes to run, and provides each process with an isolated, virtual address space in which to run. The kernel is what the GRUB boot loader loads into memory. The kernel loads device driver modules. It also allocates hardware resources such as IRQ ports, I/O addresses, and DMA channels. A recompiled kernel can lead to:
- Greatly improved speed at which kernel services operate.
- Direct support for commonly used drivers.
- Dynamic loading of appropriate drivers as modules.
- Lower memory consumption by removing unneeded components.
- Support for high-end hardware, such as memory above 4GB, hardware array controllers, symmetric multiprocessing (multiple CPU) support, and more.
Xen is based on a specially customized Linux kernel for virtual machines. The files associated with the Xen-based kernel are different from regular kernels.
In the Kernel Services, Part 2 we will discuss Best Practices and Kernel Concepts.
Subscribe to:
Posts (Atom)
