Memory Manager Subsystem in Linux Operating System:
1. Goals:
The memory manager provides the following capabilities to its clients:
Large address space: user programs can reference more memory than physically exists.
Protection: the memory for a process is private and cannot be read or modified by another process; also, the memory manager prevents processes from overwriting code and read-only-data.
Memory Mapping: clients can map a file into an area of virtual memory and access the file as memory.
Fair Access to Physical Memory: the memory manager ensures that processes all have fair access to the machine's memory resources, thus ensuring reasonable system performance.
Shared Memory: the memory manager allows processes to share some portion of their memory. For example, executable code is usually shared amongst processes.
2. External Interface:
The memory manager provides two interfaces to its functionality: a system-call interface that is used by user processes, and an interface that is used by other kernel subsystems to accomplish their tasks.
3. Subsystem Description:
Linux supports several hardware platforms. There is a platform-specific part of the memory manager that abstracts details of all hardware platforms into one common interface. All access to the hardware memory manager is through this abstract interface.
The memory manager uses hardware memory manager to map virtual addresses to physical memory addresses. When a user process accesses a memory location, the hardware memory manager translates virtual memory address to a physical address and then uses the physical address to perform the access. Because of this mapping, user processes are not aware of what physical address is associated with a particular virtual memory address. It allows memory manager subsystem to move process's memory around in physical memory. The mapping also permits two user processes to share, physical memory if regions of their virtual memory address space map to the same physical address space.
The memory manager swaps, process memory out to a paging file when it is not in use. It allows the system to execute processes that use more physical memory than available memory. The memory manager contains a daemon (kswapd). Linux uses the term daemon to refer to kernel threads; a daemon is scheduled by the process scheduler in the same way that user processes are, but daemons can directly access kernel data structures. The concept of a daemon is closer to a thread than a process.
The kswapd daemon periodically checks to see if there are any physical memory pages that have not been referenced recently. These pages are evicted from physical memory. If necessary, they are stored on disk. The memory manager subsystem takes special care, to minimize the amount of disk activity that is required. The memory manager avoids writing pages to disk if they could be retrieved another way.
The hardware memory manager detects when a user process accesses a memory address that is not currently mapped to a physical memory location. The hardware memory manager notifies Linux kernel of this page fault. It is up to memory manager subsystem to resolve the fault. There are two possibilities; either the page is currently swapped out to disk, and must be swapped back in, or the user process is making an invalid reference to a memory address outside of its, mapped memory. The hardware memory manager also detects invalid references to memory addresses such as writing to executable code or executing data. These references also result in page faults that are reported to the memory manager subsystem. If the memory manager detects an invalid memory access, it notifies the user process with a signal; if the process doesn't handle this signal, it is terminated.
4. Data Structures:
The following data structures are relevant:
vm_area: The memory manager stores a data structure with each process that records what regions of virtual memory are mapped to which physical pages. It also stores a set of function pointers that allow it to perform actions on a particular region of the process's virtual memory.
mem_map: The memory manager maintains a data structure for each page of physical memory on system. This data structure contains flags that indicate the status of the page. All page data structures are available in a vector that is initialized at kernel boot time. As page status changes, the attributes in data structure are updated.
free_area: The free_area vector is used to store unallocated physical memory pages; pages are removed from the free_area when allocated, and returned when freed.
5. Subsystem Structure:
The memory manager subsystem is composed of several source code modules; these can be decomposed by areas of responsibility into the following groups.
System Call Interface: This group of modules is responsible to present the services of memory manager to user processes through a well-defined interface.
Memory-Mapped Files (MMAP): This group of modules is responsible for supported memory-mapped file I/O.
Swap file Access (Swap): This group of modules controls memory swapping. These modules initiate page-in and page-out operations.
Core Memory Manager (Core): These modules are responsible for the core memory manager functionality that is used by other kernel subsystems.
Architecture Specific Modules: These modules provide a common interface to all supported hardware platforms. These modules execute commands to change the hardware MMU's virtual memory map, and provide a common means of notifying the rest of the memory-manager subsystem, when a page fault occurs.
6. Subsystem Dependencies:
The memory manager is used directly (via data structures and implementation functions) by each of sched, fs, ipc, and net.
