Understanding the basic shape of Unix virtual memory management

Although their implementations vary in detail, every modern Unix system (ie, everyone with mmap()) has some basic constraints that shape the general outline of their virtual memory system. While I'm talking about virtual memory statistics, it's worth running down this basic shape and what creates it.

(I say this partly because I spend part of writing yesterday's entry sorting bits of this out in my own head.)

The fundamental mmap() operation is to glue some resource (such as a portion of a file) into the process's memory address space. Multiple processes can each map the same resource into their memory space; when they do, all processes need to share the same pages of physical RAM in order to keep everyone's view of the resource in sync (in fact you want this to happen for write() based IO as well). This implies that a process's address space is effectively composited together from a bunch of entities representing different memory areas.

However, this compositing needs to involve a layer of indirection. Processes don't all map a resource at the same address space (for example, a shared library may be mapped at many different addresses), plus processes can overlay private changes on top of shared resources (eg, copy on write for various things). This implies a two step mapping; a process has 'virtual memory areas' holding information used to build its own page table (and to track private versions of pages), and these then point to a shared data structure to keep track of the actual resource, what pages it has in RAM, and so on.

(If we construe 'process' broadly, processes sometimes share VMAs; threads traditionally run in a shared address space, for example.)

Read more: Chris Siebenmann :: CSpace » blog
QR:

Posted via email from Jasper-net