Configurable 2.6 Kernel Features

Two new features available in the 2.6 kernel merit serious consideration because they can impact Linux system performance for some workloads: I/O elevators and huge TLB (Translation Look-aside Buffer) page support. These features must be explicitly enabled (for example, in the kernel configuration file or the boot kernel command line).

I/O Elevators

An elevator is a queue where I/O requests are ordered by the function of their sector on disk. Two I/O elevators are now available in the 2.6 kernel: anticipatory and deadline. The default mode is anticipatory. Using anticipatory mode, synchronous read operations are scheduled together with a delay of a few milliseconds, anticipating the "next" read operation. This mode should help read performance for commands that require multiple synchronous reads, especially during streamed writes. However, several workloads that seek all over the disk, performing reads and synchronous writes, such as database operations, can actually suffer with anticipatory I/O. For these workloads, the deadline I/O scheduler is better and can deliver up to a 10% performance improvement over the anticipatory scheduler. Select the deadline I/O scheduler by booting with elevator = deadline on the kernel command line.

Huge TLB Page Support

Huge TLB page support is now present in the 2.6 kernel as well as in the latest 2.4 kernel-based Linux distributions, such as RHEL 3. The TLB is the processor's cache of virtual-to-physical memory address translations. As such, the number of TLB entries is very limited, and a TLB miss is very costly in terms of processor cycles. With huge TLB page support, each dedicated, large TLB entry can map a 2MB or 4MB page, thus reducing the number of TLB misses, and could increase performance by a few percent for database operations. This is even more critical as more and more systems with gigabytes of physical memory are now available. Huge pages are reserved inside the kernel, are mapped by dedicated, large TLB entries, and are not pageable, making it very attractive for large database applications. A user application can use these pages either via the mmap system calls or shared memory system calls. Huge pages must be preallocated by the superuser (for example, the system administrator), preferably during system initialization when huge contiguous memory blocks are still available, before they can be used. More specifically, to use this huge TLB page support on the 2.6 kernel, you need to consider the following:

• The kernel must be built with CONFIG_HUGETLB_PAGE (under the Processor types and features section of the kernel configuration file) and CONFIG_ HUGETLBFS (under the File system section) configuration options.

• /proc/meminfo should be able to show the huge page size supported, the total number of huge pages in the system, and the number of huge pages that are still available.

• /proc/filesystem should also show a file system of type hugetlbfs configured in the kernel.

• /proc/sys/vm/nr_hugepages indicates the current number of configured huge pages in the system.

• Huge pages can be preallocated by using the following command:

   echo x >/proc/sys/vm/nr_hugepages  

  
  

  where x is the number of huge pages to be preallocated. This command can be inserted into one of the local rc initialization files so it can be executed during system initialization. (On RHEL 3 systems that are based on the 2.4 kernel technology, this can be done by echoing the value in megabytes into /proc/sys/vm/hugetlb_pool or by putting the value in the /etc/sysctl.conf file.)

• To use huge pages via mmap system calls, the superuser must first mount a file system of type hugetlbfs on the directory /mnt/huge. Any files created on /mnt/huge will use huge pages. User applications can use mmap system calls to request huge pages.

• To use huge pages via shared memory system calls (shmat / shmget), there is no need to mount hugetlbfs. However, it is possible for the same user application to use any combination of mmap and shared memory system calls to use huge pages.

It should be noted that the use of huge pages is most effective on large memory systems. Using huge pages on systems with limited physical memory can adversely affect system performance because huge pages, if they can be allocated, must be physically contiguous and are not pageable, thus making memory swapping ineffective.

In the event of any problems with your system, Linux can log the event. This allows better system management.