Introduction

The virtual memory subsystem can be considered the core of any UNIX system. This chapter discusses the implementation of the virtual memory system and the effects and impacts on almost every other subsystem in the operating system. The chapter first elaborates on some of the basic memory management issues; secondly, it outlines a more detailed analysis of how the Linux operating system incorporates virtual memory management tasks. The virtual memory subsystem enables a process (also labeled a task or default thread) to view linear ranges of bytes in the address space. This is allowed regardless of the physical layout or the fragmentation encountered in physical memory. The thread is allowed to execute in a virtual environment that appears as the entire address space of a CPU. This (supporting) execution framework results in providing a process with a large programming model. In such a scenario, a virtual view of memory storage referenced as the address space is presented to an application while the virtual memory subsystem transparently manages the virtual storage infrastructure, therefore incorporating the physical memory subsystem as well as secondary storage (see Figure 9-1).

Figure 9-1. Address space structure (generic view).

The kernel image section is also known as the identity mapped segment, whereas the kernel module section is often referred to as the page table mapped segment. See the section "Kernel Address Space" for a detailed discussion. The high reference for the address space (0xFFFF ..) is platform-dependent. On a 32-bit system, the per-process virtual address space equals 4GB, whereas on a 64-bit system, the theoretical per-process virtual address space of 2^64 is normally not fully utilized. Some systems (the actual processor per se) allow only a per-process virtual address space of 2^44.

To help you better understand the concept of memory and address space, let's begin by discussing the subsystems and challenges.