Overview of Linux memory management
32-bit architectures can reference 4 GB of physical memory
(2^32). Processors that have an MMU (Memory Management Unit) support
the concept of virtual memory: page tables are set up by the kernel
which map "virtual addresses" to "physical addresses"; this basically
means that each process can access 4 GB of memory, thinking it's the
only process running on the machine (much like multi-tasking, in which
each process is made to think that it's the only process executing on
a CPU).
The virtual address to physical address mappings are done by the
kernel. When a new process is "fork()"ed, the kernel creates a new set
of page tables for the process. The addresses referenced within a
process in user-space are virtual addresses. They do not necessarily
map directly to the same physical address. The virtual address is
passed to the MMU (Memory Management Unit of the processor) which
converts it to the proper physical address based on the tables set up
by the kernel. Hence, two processes can refer to memory address
0x08329, but they would refer to two different locations in
memory.
The Linux kernel splits the 4 GB virtual address space of a process in
two parts: 3 GB and 1 GB. The lower 3 GB of the process virtual
address space is accessible as the user-space virtual addresses and the
upper 1 GB space is reserved for the kernel virtual addresses. This is
true for all processes.
+----------+ 4 GB
| |
| |
| |
| Kernel |
| | +----------+
| Virtual | | |
| | | |
| Space | | High |
| | | |
| (1 GB) | | Memory |
| | | |
| | | (unused) |
+----------+ 3 GB +----------+ 1 GB
| | | |
| | | |
| | | |
| | | Kernel |
| | | |
| | | Physical |
| | | |
|User-space| | Space |
| | | |
| Virtual | | |
| | | |
| Space | | |
| | | |
| (3 GB) | +----------+ 0 GB
| |
| | Physical
| | Memory
| |
| |
| |
| |
| |
+----------+ 0 GB
Virtual
Memory
The kernel virtual area (3 - 4 GB address space) maps to the first 1
GB of physical RAM. The 3 GB addressable RAM available to each process
is mapped to the available physical RAM.
The Problem
So, the basic problem here is, the kernel can just address 1 GB of
virtual addresses, which can translate to a maximum of 1 GB of
physical memory. This is because the kernel directly maps all
available kernel virtual space addresses to the available physical
memory.
Solutions
There are some solutions which address this problem:
1. 2G / 2G, 1G / 3G split
2. HIGHMEM solution for using up to 4 GB of memory
3. HIGHMEM solution for using up to 64 GB of memory
1. 2G / 2G, 1G / 3G split
Instead of splitting the virtual address space the traditional way
of 3G / 1G (3 GB for user-space, 1 GB for kernel space), third-party
patches exist to split the virtual address space 2G / 2G or 1G /
3G. The 1G / 3G split is a bit extreme in that you can map up to 3 GB
of physical memory, but user-space applications cannot grow beyond 1
GB. It could work for simple applications; but if one has more than 3
GB of physical RAM, he / she won't run simple applications on it,
right?
The 2G / 2G split seems to be a balanced approach to using RAM more
than 1 GB without using the HIGHMEM patches. However, server
applications like databases always want as much virtual addressing
space as possible; so this approach may not work in those
scenarios.
There's a patch for 2.4.23 that includes a config-time option of
selecting the user / kernel split values by Andrea Arcangeli. It is
available at
href="http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.23aa1/00_3.5G-address-space-5";>his
kernel page. It's a simple patch and making it work on 2.6 should
not be too difficult.
Before looking at solutions 2 & 3, let's take a look at some more
Linux Memory Management issues.
---------------------------------------------------------------------------
Esta lista é patrocinada pela Conectiva S.A. Visite http://www.conectiva.com.br
Arquivo: http://bazar2.conectiva.com.br/mailman/listinfo/linux-br
Regras de utilização da lista: http://linux-br.conectiva.com.br
FAQ: http://www.zago.eti.br/menu.html
