How the Linux Kernel Manages Virtual Memory

Virtual Memory is Fundamental to OS Performance

Virtual memory is one of the most important, and accordingly confusing, pieces of an operating system. Understanding the basics of virtual memory is required to understand operating system performance. Beyond the basics, a deeper understanding allows a system administrator to interpret system profiling tools better, leading to quicker troubleshooting and better decisions.

The concept of virtual memory is generally taught as though it's only used for extending the amount of physical RAM in a system. Indeed, paging to disk is important, but virtual memory is used by nearly every aspect of an operating system.

In addition to swapping, virtual memory is used to manage all pages of memory, which are required for file caching, process isolation, and even network communication. Anything that queues data, you can be assured, traverses the virtual memory system. Depending on a server's role, virtual memory functionality may not be optimal. An administrator can dramatically improve overall system performance by adjusting certain virtual memory manager settings.

To optimally configure your Virtual Memory Manager (VMM), it's necessary to understand how it does its job. We're using Linux for example's sake, but the concepts apply across the board, though some slight architectural differences will exist between the Unixes.

How the Virtual Memory Manager Works

Nearly every VMM interaction involves the MMU, or Memory Management Unit, excluding the disk subsystem. The MMU allows the operating system to access memory through virtual addresses by using data structures to track these translations. Its main job is to translate these virtual addresses into physical addresses, so that the right section of RAM is accessed.

The Zoned Buddy Allocator interacts directly with the MMU, providing valid pages when the kernel asks for them. It also manages lists of pages and keeps track of different categories of memory addresses.

The Slab Allocator is another layer in front of the Buddy Allocator, and provides the ability to create cache of memory objects in memory. On x86 hardware, pages of memory must be allocated in 4KB blocks, but the Slab Allocator allows the kernel to store objects that are differently sized, and will manage and allocate real pages appropriately.

Finally, a few kernel tasks run to manage specific aspects of the VMM. Bdflush manages block device pages (disk IO), and kswapd handles swapping pages to disk.

Pages of memory are either Free (available to allocate), Active (in use), or Inactive. Inactive pages of memory are either dirty or clean, depending on if it has been selected for removal yet or not. An inactive, dirty page is no longer in use, but is not yet available for re-use. The operating system must scan for dirty pages, and decide to deallocate them. After they have been guaranteed sync'd to disk, an inactive page my be “clean,” or ready for re-use.